Requirements

Management
Practices
Software Requirement Engineering
Lecture#10
Why manage
requirements?
 Requirements management helps to ensure that
the effort you invest in requirements development
isn’t squandered.
 Effective requirements management reduces the
expectation gap by keeping all project
stakeholders informed about the current state of
the requirements throughout the development
process.
 It lets you know where you’re headed, how the
trip is going, and when you’ve arrived at your
destination.
Requirements Management
Process
 Requirements management includes all activities
that maintain the integrity, accuracy, and currency
of requirements agreements throughout the
project.
 Figure 27-1 shows the core activities Of
requirements management in four major
categories:
 Version control
 Change control
 Requirements status tracking
 Requirements tracing
Requirements version
control
Version Control: Uniquely identifying different versions of an
item.
 Applies at the level of both individual requirements and
requirements sets, most commonly represented in the form
of documents.
 Begin version control as soon as you draft a requirement or a
document so you can retain a history of changes made.
 Every version of the requirements must be uniquely
identified.
 Changes must be clearly documented and communicated to
everyone affected.
 Each circulated version of a requirements document or each
requirement in a tool should include a revision history that
identifies the changes made, the date of each change, the
individual who made the change, and the reason for each
change.
 The simplest version control mechanism is to manually label
each revision of a document according to a standard convention.
 Schemes that try to differentiate document versions based on
dates are prone to confusion. I use a convention that labels the
first version of any new document with its title and “Version 1.0
draft 1.”
 The next draft keeps the same title but is identified as “ Version
1.0 draft 2.”
 The author increments the draft number with each iteration until
the document is approved and baselined.
 At that time, the version identifier is changed to “Version 1.0
approved,” again keeping the same document title. The next
version is either “Version 1.1 draft 1” for a minor revision or
“Version 2.0 draft 1” for a major change. (Of course, “major”
and “minor” are subjective and depend on the context.) This
scheme clearly distinguishes between draft and baselined
document versions, but it does require manual discipline on the
part of those who modify the documents.
Requirement attributes
 Each requirement as an object with
properties that distinguish it from other
requirements.
 OR , each requirement should have

supporting pieces of information or

attributes associated with it.
 You can store attribute values in a

document, a spreadsheet, a database, or—

most effectively—a requirements
management tool.
 Following is a list of potential requirement
attributes to consider:
◦ Date the requirement was created
◦ Current version number of the requirement
◦ Author who wrote the requirement
◦ Priority
◦ Status
◦ Origin or source of the requirement
◦ Rationale behind the requirement
◦ Release number or iteration to which the
requirement is allocated
◦ Stakeholder to contact with questions or to make
decisions about proposed changes
◦ Validation method to be used or acceptance criteria
Tracking requirements
status
“How are you coming on implementing that subsystem,
Yvette?” asked the project manager, Dave.
 “Pretty good, Dave. I’m about 90 percent done.”
 Dave was puzzled. “Didn’t you say you were 90 percent done a
couple of weeks ago?” he asked.
 Yvette replied, “Yes, I thought I was, but now I’m really 90
percent done.”
 Software developers are sometimes overly optimistic when
they report how much of a task is complete.
 The common “90 percent done” syndrome doesn’t tell Dave
much about how close Yvette really is to finishing the
subsystem.
 But suppose Yvette had replied, “Pretty good, Dave. Of the 84
requirements for the subsystem, 61 are implemented and
verified, 14 are implemented but not yet verified, and I haven’t
implemented the other 9 yet.”
 Tracking the status of each functional requirement
throughout development provides a more precise gauge of
project progress.
Why manage changes?
 Software change isn’t a bad thing; in fact,
it’s necessary.
 It’s virtually impossible to define all of a
product’s requirements up front.
 The world changes as development
progresses: new market opportunities arise,
regulations and policies change, and
business needs evolve.
 Therefore an effective software organization
must respond to changes so that the product
they build provides timely customer value.
Change control policy
 Management should communicate a policy that states, how
project teams will handle proposed changes in requirements
and all other significant project artifacts.
 Policies are meaningful only if they are realistic, add value,

and are enforced.

The following change control policy statements can be
helpful:
1. All changes must follow the process. If a change request is
not submitted in accordance with this process, it will not be
considered.
2. No design or implementation work other than feasibility
study will be performed on unapproved changes.
Change control policy
3- Simply requesting a change does not guarantee that it will
be made. The project’s change control board (CCB) will
decide which changes to implement.

4- Impact analysis must be performed for every change.

5- The rationale behind every approval or rejection of a

change request must be recorded.
Change Control Process
 Figure 28-1 illustrates a template for a change control
process description to handle requirements modifications.
include the following four components in all process
descriptions:
1. Entry criteria, the conditions that must be satisfied
before the process execution can begin
2. The various tasks involved in the process, the
project role responsible for each task, and other
participants in the task
3. Steps to verify that the tasks were completed
correctly
4. Exit criteria, the conditions that indicate when the
process is successfully completed
1. Purpose and scope
 Describe the purpose of this process and
the organizational scope to which it applies.
 Indicate whether any specific kinds of

changes are exempted, such as changes in

interim work products.
 Define any terms that are necessary for

understanding the rest of the document.

2. Roles and
responsibilities
 List the project team roles that participate in the change
control activities and describe their responsibilities.
3.Change request status
 A change request passes through a defined
life cycle of states.
 can represent these states by using a state-

transition diagram as illustrated in Figure

28-2.
 Update a request’s status only when the

specified transition criteria are met either

for just a single requirement statement or a
set of related development work products.
4. Entry criteria
 Entry criterion for change control process is
that a change request with all the necessary
information has been received through an
approved channel.
 All potential originators should know how to

submit a change request.

 Your change tool should assign a unique

identifier to each request and route all

changes to the Request Receiver.
5. Tasks
 This section of the process describes the tasks that are
performed to handle a single change request.
 5.1 Evaluate change request:
 Begin by evaluating the request for technical feasibility,
cost, and alignment with the project’s business
requirements and resource constraints.
 CCB Chair might assign an Evaluator to perform impact
analysis, risk and hazard analysis, or other assessments.
 Ensures the consequences of accepting the change are
understood.
 The Evaluator and the CCB should also consider the
business and technical implications, if any, of rejecting the
request.
5.2 Make change decision
 CCB makes decision whether to approve or
reject the change.
 The CCB gives each approved change a

priority or target implementation date, or it

allocates the change to a specific iteration
or release.
 It might simply add a new requirement to

the product backlog of pending work.

 The CCB updates the request’s status and

notifies all affected team members.

5.3 Implement the change
Modifiers(someone who implement change)
updates the affected work products as
necessary to fully implement the change.
 Use requirements trace information to find

all the parts of the system that the change

touches, and revise the trace information if
necessary to reflect the changes made.
5.4 Verify the change
 Requirements changes are verified through a
peer review to ensure that modified deliverables
correctly address all aspects of the change.
 Multiple team members might verify the changes
made in work products through testing or review.
 After verification is complete, the Modifier stores
updated work products in the appropriate
locations per the project’s document and code
management conventions.
6. Exit criteria
 Satisfying the following exit criteria indicates that change
control process was properly completed:
1. The status of the request is Rejected,
Closed, or Canceled.
2. All modified work products are updated
and stored in the correct locations.
3. The relevant stakeholders have been
notified of the change details and the
status of the change request.