Requirements Development &
Management
Lecture 4
1
Requirements development and management
• Figure shows, we
subdivide requirements
development into
elicitation, analysis,
specification, and validation
• These
(Abran et al. 2004). disciplin
sub thees
encompass
involved activities
explorin
evaluating,
withall documenting,
g,
and confirming the
requirements for a
product.
• Regardless of what development life cycle your project is following
—be it pure waterfall, iterative, incremental, agile, or some hybrid
—these are the things you need to do regarding requirements.
• Depending on the life cycle, you will perform these activities at
different times in the project and to varying degrees of depth or
2 detail.
Requirements Engineering Activities
Requirements Requirements
Requirements Requirements
Elicitation Analysis and
Specification Validation
Negotiation
User Needs
Domain Information Agreed
Existing System Information Requirements Requirements
Regulations Document
Standards
Elicitation
Elicitation encompasses all of the activities
involved with discovering requirements, such as
interviews, workshops, document analysis,
prototyping, and others.
The key actions are:
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.
4
Analysis
Analyzing requirements involves
Accomplishment of a rich and more precise
understanding of each requirement and
Representing sets of requirements in multiple
ways.
5
Principal Activities
Analyzing the information received from users to
distinguish their task goals from functional requirements,
quality expectations, business rules, suggested solutions
and other information.
Decomposing high-level requirements into an
appropriate level of detail.
Deriving functional requirements from other
requirements information.
Understanding the relative importance of quality
attributes.
Negotiating implementation priorities.
Identifying gaps in requirements or unnecessary
requirements as they relate to the defined scope.
6
Specification
Requirements specification involves
representing and storing the collected
requirements knowledge in a persistent
and well-organized fashion.
The principal activity is:
Translating the collected user needs into written
requirements and diagrams suitable for
comprehension, review and use by their intended
audiences.
7
Validation
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.
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.
Iteration is a key to requirements development
success.
Plan for multiple cycles of exploring requirements,
progressively refining high-level requirements into
8 more precision and detail, and confirming
Requirements management
Requirements management activities include
the following:
Defining the requirements standard, 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.
9
Requirements management
Negotiating new commitments based on the
estimated impact of requirements changes.
Defining the relationships and dependencies that
exist between requirements.
Tracing individual requirements to their
corresponding designs, source code and tests.
Tracking requirements status and change activity
throughout the project.
1
0
When bad requirements happen to good
people
Insufficient user involvement
Customers often don’t understand why it is so
essential to
work hard on eliciting requirements and assuring their
quality.
Developers might not emphasize user involvement,
perhaps because they think they already understand
what the users need.
In some cases it’s difficult to gain access to people who
will actually use the product, and user substitutes
don’t always understand what users really need.
Insufficient user involvement leads to late-breaking
requirements that generate rework and delay
completion.
Another risk of insufficient user involvement,
1
1
particularly when reviewing and validating the
Overlooked stakeholders
Most products have several groups of users who
might use different subsets of features, have different
frequencies of use, or have varying levels of
experience.
If you don’t identify the important user classes
for your product early on, some user needs
won’t be met.
After identifying all user classes, make sure that
each has a voice.
Besides obvious users, think about maintenance
and field support staff who have their own
requirements, both functional and
nonfunctional.
You might have stakeholders who don’t even know
the project exists, such as government agencies that
mandate standards that affect your system, yet you
1
need to know about them and their influence on the
2project.
Benefits from a high-quality requirements
process
Some people mistakenly believe that time spent
discussing requirements simply delays delivery by
the same duration.
This assumes that there’s no return on investment from
requirements activities. In actuality, investing in good
requirements will virtually always return more than it
costs.
The potential payoff includes:
Fewer defects in requirements and in the delivered product.
Reduced development rework.
Faster development and delivery.
Fewer unnecessary and unused features.
Lower enhancement costs.
Fewer miscommunications.
Reduced scope creep.
Reduced project confusion.
Higher customer and team member satisfaction.
1 Products that do what they’re supposed to do.
3
1
14
4
