Software Engineering

296
CHAPTER 17 
Software Requirements Definition
The initial structure concepts may establish, if determined necessary, more than 
one software configuration item to provide a satisfactory solution. Alternative 
structural concepts should be considered and viable structures evaluated via trade 
studies and risk assessments during systems analysis. If multiple software con-
figuration items are identified, then the project plan, work breakdown structure 
(WBS), and specification tree must be revised to reflect this architectural decision.
As the physical architecture matures, it may challenge the validity or cor-
rectness of the functional architecture or operational model. In addition, the 
physical structure of the product may affect the design of or requirements for 
the computational environment. These conflicts must be captured in problem 
reports, viable alternatives identified, and the alternatives evaluated against pro-
ject objectives, product quality metrics, and risks.
⁎
Note: 
This is where the process described in this book disregards the design 
of the computing environment and focuses on the design of the software product. 
Until this time, there were trade-offs between the computing environment and 
the software product that needed to be considered to achieve a proper balance 
between the computing environment and software product requirements and 
performance. It makes sense that the computing environment implementation 
team would undertake a similar approach to synthesizing and analyzing 
computing environment design alternatives. Since this book is about software 
engineering, computing environment design and implementation have not been 
addressed in detail.
4. 
Analyze product alternatives, conflicts, and trade-offs
. The SWE-IPT must 
evaluate identified conflicts between the software requirements and functional 
and physical architectures to determine a preferred architectural solution. 
The architectural alternatives must be analyzed to determine if they can be 
achieved within project cost and schedule objectives and to identify conflicts 
with stakeholder needs and expectations. The architectural alternatives should 
be prioritized and a preferred solution recommended to the SWE-IPT. The 
preferred design alternative should be analyzed to ensure that it represents a 
congruent combination of software requirements and functional and physical 
architectures.
The preferred design alternative should be analyzed and evaluated to under-
stand the implementation challenges and to identify any risk inherent with its 
adoption. Identified risks must be assessed to devise approaches for eliminat-
ing, avoiding, or reducing risks to an acceptable level. It is imperative that risks 
be identified, quantified, and mitigated before adopting a design alternative. 
Adopting architectural decisions with inherent risks places the software devel-
opment project in jeopardy. Architectural modifications later in the project will 
incur greater cost and potential schedule delays. Risk assessment reports must 
be prepared to capture the results of the risk appraisal including the probability 
of occurrence and the consequences to the project should the risk be realized.
If the preferred architectural alternative does not impact project and techni-
cal plans, it can be adopted as an architectural design decision. Architectural 

---

297
alternatives that negatively impact the scope of technical plans must be docu-
mented in a software change proposal. Change proposals must be submitted to 
the technical CCB for authorization. If a change proposal impacts project plans 
beyond the authority of the technical CCB, it must be submitted to the project 
CCB for authorization. These software change proposals represent project-level 
adjustments that require additional resources and modification of project plans, 
schedules, and resource allocations.
5. 
Establish the software requirements allocations
. As the operational model 
matures, the functional and physical architectures should reinforce that the 
product requirements are achievable within project objectives. The operational 
model should be utilized to allocate requirements among the software configura-
tion items, the computing environment, and the software product interfaces. The 
SWE-IPT should prepare requirements specifications for these elements of the 
software architecture. The SWE-IPT should prepare the requirement traceability 
matrix to associate stakeholder needs and expectations, project objectives, and 
facets of the operational process to the requirements allocated among the archi-
tectural elements.
6. 
Prepare software post-development process concepts
. The SWE-IPT should 
evaluate the requirements for each of the software post-development processes. 
The SWE-IPT should apply the systems engineering practices to establish an 
initial concept of operation for each of the software post-development pro-
cesses. Each of the software post-development process concept documents 
should address the scope of the process, its operational behaviors, and initial 
functional and physical architectures.
7. 
Prepare and document risk mitigation plans
. The SWE-IPT must prepare risk 
mitigation plans for each identified risk. Risks must be continually monitored 
until the risk is eliminated. Risk mitigation plans should identify the approach 
to monitoring a risk, the criteria that would activate contingency plans, and the 
course of action that would be executed if the risk were deemed unavoidable.
8. 
Revise the work breakdown structure
. The SWE-IPT must review and update 
the work breakdown structure to reflect the impact of architectural decisions and 
adopted change proposals. The work packages, associated tasks, and resource 
allocations should be adjusted to reflect the enhanced understanding of the effort 
that will be necessary to architect, implement, and test the software product and 
post-development processes. Some tasks may be eliminated or reduced in scope, 
others will demand more time and resources, and new tasks might be created. 
The WBS must be a flexible mechanism that can be adjusted from initial plan-
ning estimates to reflect architectural decisions and adopted change proposals.
9. 
Refine the product specification tree
. As a result of identifying the software con-
figuration items, the requirements for software documentation must be revisited 
to align the specification tree with the adopted architectural structure of configu-
ration items. The specification tree should reflect the software hierarchy of doc-
umentation required for each identified configuration item. It must be extended 
and updated to reflect the software plans, specifications, documents,