Characteristics of Requirements Statement and Collection,

Ambiguous Requirement

Requirements Management Process, Requirement Attributes,

Software Requirements and Risk Management

Change Control Process

 Characteristics of Requirements Statement and
Collection
• Clear and concise
• Consistent and unambiguous
• Testable and measurable
• Relevant to stakeholders’ needs
• Prioritized according to importance
 Key Factors in Requirements Collection
• Identifying stakeholders
• Effective communication techniques
• Utilizing tools like interviews, surveys, and workshops
• Validating and verifying collected requirements
 Ambiguous Requirements
Definition:
Requirements that can be interpreted in more than one way

Causes:

Vague language
Lack of stakeholder clarity
Insufficient validation
Example: "The system should respond quickly."
 Impacts of Ambiguity in Requirements
• Misinterpretations and misunderstandings
• Increased development time and costs
• Decreased quality and user satisfaction
 Best Practices to Avoid Ambiguity
• Use precise language
• Validate requirements with stakeholders
• Leverage templates and checklists
Requirements Management Practices

• Requirement Management Process

• Requirement attributes
• Requirements Version Control
Requirements Management Process
Requirements Management Process
• Requirements management includes all activities that maintain the
integrity, accuracy, and currency of requirements agreements throughout
the project.

• Figure shows the core activities of requirements management in four

major categories: version control, change control, requirements status
tracking, and requirements tracing.
Requirements Management Process
Requirement Attributes
Requirement Attributes

• Think of each requirement as an object with properties that distinguish it

from other requirements.

• In addition to its textual description, each requirement should have

supporting pieces of information or attributes associated with it.

• These attributes establish a context and background for each requirement.

• You can store attribute values in a document, a spreadsheet, a database, or

most effectively a requirements management tool.
Requirement Attributes
• Following is a list of potential requirement attributes to consider using RM Tool:
▫ 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
Requirements Version Control
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.
• Every version of the requirements must be uniquely identified.
• Every team member must be able to access the current version of the
requirements.
• Changes must be clearly documented and communicated to everyone affected.
• To minimize confusion and miscommunication, permit only designated individuals
to update the requirements, and make sure that the version identifier changes
whenever an update is made.
Tracking Requirements Status / Software
Risk Management
 Tracking Requirements Status / Software Risk Management
• Tracking the status of each functional requirement throughout development
provides a more precise gauge of project progress.

• Classifying requirements into several status categories is more meaningful

than trying to monitor the percent completion of each requirement or of the
complete release baseline.

• Update a requirement’s status only when specified transition conditions are

satisfied.
 Tracking Requirements Status / Software Risk Management
Table: Suggested requirement statuses
Status Description
Proposed The requirement has been requested by an authorized source.
In Progress A business analyst is actively working on crafting the requirement.
Drafted The initial version of the requirement has been written.
Approved The requirement has been analyzed, its impact on the project has
been estimated, and it has been allocated to the baseline for a
specific release. The key stakeholders have agreed to incorporate the
requirement, and the software development group has committed
to implement it.
 Tracking Requirements Status / Software Risk Management
Table: Suggested requirement statuses

Status Description
Implemented The code that implements the requirement has been designed,
written, and unit tested. The requirement has been traced to the
pertinent design and code elements. The software that
implemented the requirement is now ready for testing, review, or
other verification.
Verified The requirement has satisfied its acceptance criteria, meaning that
the correct functioning of the implemented requirement has been
confirmed. The requirement has been traced to pertinent tests. It is
now considered complete.
 Tracking Requirements Status / Software Risk Management
Table: Suggested requirement statuses

Status Description

Deferred An approved requirement is now planned for implementation in a

later release.
Deleted An approved requirement has been removed from the baseline.
Include an explanation of why and by whom the decision was made
to delete it.
Rejected The requirement was proposed but was never approved and is not
planned for implementation in any upcoming release. Include an
explanation of why and by whom the decision was made to reject it.
Why Manage Requirements?
Why Manage Requirements?
• Whether your project is following a sequential development life cycle, one of the
various agile life cycles, or any other approach, managing the requirements is an
essential activity.

• Requirements management helps to ensure that the effort you invest in

requirements development isn’t wasted.

• Effective requirements management reduces the expectation gap by keeping all

project stakeholders informed about the current state of the requirements
throughout the development process.
Why Manage Changes?
Why Manage Changes?

• The world changes as development progresses: new market opportunities

arise, regulations and policies change, and business needs evolve.

• An effective software team can nimbly respond to necessary changes so that

the product they build provides timely customer value.
Why Manage Changes?

• An organization that’s serious about managing its software projects must

ensure that:
▫ Proposed requirements changes are thoughtfully evaluated before being
committed to.
▫ Appropriate individuals make informed business decisions about requested
changes.
▫ Change activity is made visible to affected stakeholders.
▫ Approved changes are communicated to all affected participants.
▫ The project incorporates requirements changes in a consistent and effective
fashion.
Change Control Process / Policy
Change Control Process / Policy
• Management should communicate a policy that states its expectations of
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:

▫ All changes must follow the process. If a change request is not submitted in
accordance with this process, it will not be considered.
Change Control Process / Policy
▫ No design or implementation work other than feasibility exploration will be
performed on unapproved changes.
▫ 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.
▫ The contents of the change database must be visible to all project stakeholders.
▫ Impact analysis must be performed for every change.
▫ Every incorporated change must be traceable to an approved change request.
▫ The reason behind every approval or rejection of a change request must be
recorded.