Software Engineering

PDR Planned Date Delayed
CDR Readiness Criteria
CDR Completion Criteria
Phase Completion Delay
(Phase Overlap)
Phase Completion 
Slippage
Software Requirements Definition
Preliminary Architecture Definition
Completion Criteria
Planned Completion Date
Preliminary Architecture Definition
FIGURE 9.1
Phase-dependent schedule and milestones.

---

166
CHAPTER 9 
Software Requirements Management
9.2 
Specifying requirements
Specifying software requirements involves close, careful, and thorough exami-
nation of the software product’s role in operational or business processes. 
Requirements statements may appear to be straightforward, but beneath the surface 
there may be many difficulties associated with implementing and testing the condi-
tions stipulated by a requirement. There are nine principles that should be applied 
to ensure that requirements are accurately stated, may be satisfied within estab-
lished project constraints, and do not adversely affect post-development processes 
or life-cycle costs. These principles are:
1. 
Requirements express what a product must do and how well it must operate. 
Every requirement should identify an operational function and its associated 
measures of effectiveness. At the software product echelon, the requirements 
should address the practical functions the software product is intended to per-
form. Each function must be measureable in terms of the acceptable range of 
performance necessary for the product to be acceptable to stakeholders. At 
lower levels, the requirements should address individual elements of the product 
design. Lower-level requirements express functions in terms of data processing 
procedures and must identify the acceptable range of performance necessary for 
the product to contribute to product execution.
2. 
Requirements must be unambiguous. Requirements should not be expressed 
using language that may be vague or unclear. A properly stated requirement 
should be written in a manner that leads to one, and only one, interpretation. An 
unambiguous statement is explicit (expressing all details in a clear and obvious 
way, leaving no doubt as to the intended meaning), unequivocal (allowing for 
no doubt or misinterpretation), and distinct (clearly different and separate from 
others). The natural language in which requirements are stated is inherently 
imprecise with words having more than one meaning or connotation. Therefore, 
the requirements analysis tasks are intended to ensure that every requirement 
is properly stated to prohibit misunderstanding or interpretation by being sup-
ported with adequate analytical documentation.
3. 
Use design models to express concepts and eliminate potential confusion. 
Modeling should be used to express design concepts to stakeholders and mem-
bers of the development team. Models may be used to express the behavior 
(functions and performance) of a product and its characteristics. Models may be 
static (e.g., drawing or diagram) or dynamic (e.g., executable, mock-up or pro-
totype, simulation), and should be used wherever necessary to explain in greater 
detail the meaning of the requirements.
4. 
Requirements should not impose unnecessary design or implementation con-
straints. A constraint limits the freedom of the development team and restricts 
the solution space. Requirements that enter the realm of the solution should be 
written as a suggestion to clarify stakeholder desires.

---