1

Software Requirement
Engineering (SWE – 205)
Software Engineering Department
Sir Syed University of Engineering & Technology
Week No. 1
 2

Content
• Software Lifecycle
• Introduction to Requirements Engineering: Why, What and How
• What are requirements: Sub-disciplines of software requirements
engineering
 3

SDLC: Software Development Life Cycle

• The Software Development Life Cycle (SDLC), or System Development
Life Cycle in systems engineering, information systems and software
engineering, is the entire process of formal, logical steps taken to
develop a software product.
• SDLC is the structure followed by a development team within the
software organization. It aims to produce quality software that exceeds
customer expectations, meets deadlines and cost estimates.
 4

SDLC Phase
 5

Where are the requirements?

 6

Why RE?
• Many of the problems encountered in SW development are attributed
to shortcoming in requirement gathering and documentation process.

• We cannot imagine start building a house without being fully satisfied

after reviewing all the requirements and developing all kinds of maps
and layouts but when it comes to software we really do not worry too
much about paying attentions to this important phase.

The Root Causes of Project Success and Failure
• The first step in resolving any problem is to
understand the root causes.
➢ The Standish Group survey study noted the
three most commonly cited factors that
caused projects to be "challenged" :
✓ Lack of user input: 13 percent of all
projects
✓Incomplete requirements and
specifications: 12 percent of all projects
✓Changing requirements and specifications:
12 percent of all projects
8
• Management problems of resources
▫ Failure to have enough money
▫ Lack of support
▫ Failure to impose proper discipline and
planning
• The survey shows that at least a third of
development projects run into trouble for
reasons that are directly related to requirements
gathering, requirements documentation, and
requirements management.
 9

According to the Standish study, the three most important factors were

➢ User involvement
➢ Executive management support
➢ Clear statement of requirements
 deemed failures, what were the primary causes of those failures? (Select up to 3)
% 40% 60% 80% 100%
Global Total
high Medium Somewhat low Very low Change in organization’s priorities 39%

Common Reasons
% due to rounding.
Change in project objectives
Inaccurate requirements gathering
37%
35%

for Project Failure

of the projects completed within your
Inadequate vision or goal
for the project
29%

…? Inadequate/poor communication 29%

Opportunities and risks were 29%
al Total not defined
• In the 10th Global Project Inaccurate cost estimates 28%
Management Survey69% by PMI, Poor change management 28%
4000+ Project Management
62% Inadequate sponsor support 26%
Practitioners globally were asked Resource dependency 26%
the following 57%
question: Inaccurate task time estimate 25%
• Of the projects started in your Inexperienced project manager 22%
52%in the past 12
organization Limited/taxed resources 21%
months that52%
were deemed Inadequate resource forecasting 18%
failures, what were the primary Team member procrastination 13%
causes of those failures? (Select
32% Task dependency 12%
up to 3) Other 10%
%
0% 20% 30% 10 40%
30% 50% 70%
 12

–Definitions –
 13

IEEE-Standard 610.12 (1990)

• A requirement is:
1. “A condition or capability needed by a user(be it person or system) to
solve a problem or achieve an objective.”
2. “A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or other
formally imposed document.”
 14

Requirement: A definition

• According to Wiegers & Beatty (2013):

▫ “[A requirement is a] statement of a customer need or objective, or of a

condition or capability that a product must possess to satisfy such a need or
objective. A property that a product must have to provide value to a
stakeholder.”
 15

Requirement form the basis for

• Project planning
• Risk management
• Acceptance testing
• Trade off
• change control
Requirement Engineering
According to International Requirements Engineering Board (IREB):
• Requirements engineering is a cooperative, iterative, incremental
process, aimed at guaranteeing that:
▫ All relevant requirements are known and understood with the necessary
degree of refinement,
▫ The stakeholders involved come to a satisfactory agreement concerning the
known requirements,
▫ All requirements have been documented as defined by the documentation
guidelines or specification guidelines.
Sub-disciplines of Requirements Engineering

Figure: Sub-discipline of Software Requirements Engineering

Requirement Development
• “Requirements Development is a process that consists of a set of
activities that produces requirements for a product. The purpose of
Requirements Development (RD) is to produce and analyze customer,
product, and product component requirements.
Requirement Development (Cont..)
• Requirements development is subdivided into:
▫ Elicitation,
▫ Analysis,
▫ Specification, and
▫ Validation.

• These sub-disciplines encompass all the activities involved with exploring,

evaluating, documenting, and confirming the requirements for a product.
Elicitation
• Elicitation encompasses all of the activities involved with discovering
requirements, such as:
▫ Interviews,
▫ Workshops,
▫ Document analysis,
▫ Prototyping,
▫ Test Scenarios
▫ and others.
Elicitation (Cont..)
• The key actions of Elicitation process are:
▫ Identifying the product’s expected user classes and other stakeholders.
▫ Understanding user tasks and goals and the business objectives with which
those tasks align
▫ Learning about the environment in which the new product will be used.
▫ Working with individuals who represent each user class to understand their
functionality needs and their quality expectations.
Elicitation (Cont..)
• Requirements elicitation typically takes either a usage-centric or a product-
centric approach.
• The usage-centric strategy emphasizes understanding and exploring user
goals to derive the necessary system functionality.
• The product-centric approach focuses on defining features that you expect
will lead to marketplace or business success.
Analysis
• “The process of classifying requirements information into various
categories, evaluating requirements for desirable qualities, representing
requirements in different forms, deriving detailed requirements from high-
level requirements, negotiating priorities, and related activities.”

• Following are the principal activities:

▫ Allocating requirements to software components defined in the system
architecture
▫ Negotiating implementation priorities
▫ Identifying gaps in requirements or unnecessary requirements as they
relate to the defined scope
Specification
• “The process of documenting a software application's requirements in a
structured, shareable, and manageable form. Also, the product from this
process.”
• The principal activity is:
▫ Translating the collected user needs into written requirements and
diagrams suitable for comprehension, review, and use by their intended
audiences.
Validation
• “The process of evaluating a project deliverable to determine whether it
satisfies customer needs. Often stated as "Are we building the right product?”
• (Verification: “Are we building the product right?”)
• Requirements validation confirms that you have the correct set of
requirements information that will enable developers to build a solution that
satisfies the business objectives.
Validation (Cont..)
• The central activities are:
▫ Reviewing the documented requirements to correct any problems before
the development group accepts them.
▫ Developing acceptance tests and criteria to confirm that a product based
on the requirements would meet customer needs and achieve the business
objectives.
Requirement Development
• Iteration is a key to requirements development success.
• Plan for multiple cycles of exploring requirements, progressively refining
high-level requirements into more precision and detail, and confirming
correctness with users.
Requirement Management
• Requirements management activities include the following:
▫ Defining the requirements baseline, a snapshot in time that represents an
agreed-upon, reviewed, and approved set of functional and nonfunctional
requirements, often for a specific product release or development
iteration.
▫ Evaluating the impact of proposed requirements changes and incorporating
approved changes into the project in a controlled way.
Requirement Management (Cont..)
• Requirements management activities include the following:
▫ Keeping project plans current with the requirements as they evolve
▫ Negotiating new commitments based on the estimated impact of requirements
changes
▫ Defining the relationships and dependencies that exist between requirements
▫ Tracking individual requirements to their corresponding designs, source code, and
tests
▫ Tracking requirements status and change activity throughout the project
Boundary b/w RD and RM