Software Engineering

FIGURE 7.2
Conceptual application of software engineering practices.

---

136
CHAPTER 7 
Understanding Software Requirements
practices may be repeated, as necessary, to revise, refine, or elaborate the software 
product architecture.
Each of the first three stages of software development is intended to progress 
the software architectural definition toward a state of specificity that is sufficient to 
guide software implementation. Unfortunately, the titles of these stages are 
similar
 
to the titles of the software engineering practices. This similarity has caused confu-
sion. Software development practitioners mistakenly assumed that only the identi-
fied software engineering practice was to be performed during these early stages 
of development. However, it is essential for software engineering practices to be 
applied, as needed, within each stage of development to eliminate risks or to estab-
lish a design solution.
Historically, the preliminary design stage resulted in an allocation of require-
ments throughout a functional hierarchy. Functional components and units were 
inappropriately considered elements of the preliminary design configuration. The 
distinction between a functional and physical architecture was not comprehended 
since software, as a design medium, resembled functional notations. Software 
languages involve statements that resemble mathematical or logical functions. 
Early programming languages involved procedures, functions, and subroutines as 
their basic structural elements. Therefore, it was easy for software practitioners to 
assume that the architectural definition was complete when the functional decom-
position was fully established. However, it must be understood that every product 
has a physical configuration. The functional analysis and allocation practice enables 
software requirements to be translated into the essential data processing actions the 
software product must be able to perform. However, this does not conclude the defi-
nition of the software architecture. The physical configuration must be synthesized 
to provide a coherent, noncomplex solution.
Each of the software engineering practices 
must
 be utilized whenever its sphere 
of influence is implicated by the delineation of the problem/solution space. This 
iteration of software engineering practices must always revisit the requirements 
analysis activity to revise or refine the software product requirements. For example 
(see 
), during the detailed architecture definition stage of development, 
the requirements analysis practice occurs twice. The first occurrence addresses the 
specification of structural units and the second occurrence addresses the specifica-
tion of structural components.
During software requirements definition, there may be stakeholder needs that 
necessitate modeling or prototyping efforts to ensure that stakeholder needs are 
understood, to investigate design challenges, and to minimize risks to the devel-
opment effort. These analytical tools should be used to ensure that the software 
requirements are unambiguously specified. This undertaking must be considered an 
excursion into the realm of design for the purpose of clarifying stakeholder needs. 
The term 
excursion
 is used to emphasize that it represents a departure from the 
normal or planned application of software engineering practices. The development 
of models or prototypes should be achieved by rapid application of software engi-
neering techniques to establish models or prototypes for the purpose of clarifying 

---