Software Engineering

167
9.2 
Specifying requirements
5. 
Requirements should be challenged if they appear excessive or consequential. 
Stakeholder needs should be understood by challenging the operational or busi-
ness demands for a requirement. Such challenges, if substantiated, improve 
the understanding of the development team and clarify any assumptions that 
may have been inferred from initial consultations. Stakeholders have grandiose 
expectations and little appreciation for the intricacy associated with some soft-
ware gymnastics (i.e., the performance of a series of complex mental or physical 
operations with great agility and skill). Many requirements may be simplified or 
diminished when stakeholders are made aware of their exaggerated demands.
6. 
Requirements impose costs and schedule ramifications. Every requirement 
involves a cost associated with product development, post-development opera-
tions, or product sustainment. Requirements should be analyzed to understand the 
life-cycle cost implications of each requirement. There may be alternative ways 
to express a requirement that alleviate software development exposure to risks.
7. 
Requirements may foster design complexity. Requirements may be stated in a 
manner that implies or amplifies product complexity. Diminishing the complex-
ity of the product is an imperative principle that reduces product development 
and sustainment costs, as well as promotes ease of use. Trade-off analysis 
should be performed to evaluate alternative requirement articulations to deter-
mine their impact on design complexity.
8. 
Requirements should not relinquish control over interface definitions. Whenever 
a software product must interface with another system, whether it is operational 
or under development, the software development team must participate in the 
definition of the interface if it is to be held accountable. Whenever the span of 
control of the software development team is relinquished, their ability to prop-
erly plan the scope of the development effort is impacted. External systems may 
be aging and in need of technology refreshment or redevelopment. It is impor-
tant to understand the longevity of the interfacing systems before mandating 
interface control. Redefining an interface may provide significant improvement 
in software performance.
9. 
Risks always originate with the requirements. Requirements should be assessed 
to identify potential risks to achieving project success. Requirements are 
the source of all risks and the risks imposed by each requirement should be 
appraised before the requirement is embraced. Requirements that involve severe 
risks should be simplified to permit the initial software delivery to be achieved 
within costs and project constraints. The design and implementation of a risk-
burdened requirement can then be pursued in parallel without jeopardizing 
project success. Requirements should be evaluated by answering the following 
questions:
●
  Can the requirement be satisfied without consuming a disproportionate 
amount of technical resources?
●
  What are the potential consequences that may arise if the requirement cannot 
be satisfied?

---