Software Engineering

43
Software Engineering. DOI: 
© 
2012
 Published by Elsevier Inc. All rights reserved.
2013
http://dx.doi.org/10.1016/B978-0-12-407768-3.00003-3
Software Architecture
3
CHAPTER 
CHAPTER OUTLINE
3.1  Stakeholder needs relationships and dependencies .............................................. 46
3.2  Software requirements baseline relationships and dependencies ........................... 48
3.3  Computing environment relationships and dependencies ....................................... 49
3.4  Test and evaluation relationships and dependencies ............................................. 49
3.5  Functional architecture relationships and dependencies ....................................... 50
3.6  Physical architecture relationships and dependencies .......................................... 51
3.7  Post-development process relationships and dependencies ................................... 51
3.8  Motivation for the software architecture ............................................................... 52
This chapter examines the software architecture that is the representation of an inte-
grated software product and provides the foundation for software implementation. 
Because of the complex nature of a software product, there are several perspectives 
that must be comprehended to describe a software product. First, a software prod-
uct is being developed to satisfy customer and stakeholder needs and expectations. 
Therefore, the software product requirements need to be agreed upon by all stake-
holders and entered into the configuration management system as a requirements 
baseline. This baseline permits the tracking of change proposals against the base-
lined requirements.
The second element of the software architecture is the functional architecture 
that depicts the operational process, functional decomposition, performance, and 
specialty-engineering characteristics of the software product. The functional decom-
position must address the behavior of the software product including aspects, such 
as data security, error and failure recovery, and safety-related actions. These behav-
iors have erroneously been referred to as nonfunctional requirements. These require-
ments should be considered specialty-engineering mandates that must be addressed 
within the functional architecture. Failure detection and response/recovery functions 
directly impact the software product’s dependability coefficient. Product complex-
ity, architectural integrity, and resilience directly affect the software product’s main-
tainability coefficient and the ability to enhance, fortify, and extend functionality in 
future versions of the software product. However these nonfunctional requirements 
are specified, they must be incorporated into the functional architecture, and their 
behaviors, in a stimulus-response scenario, explicitly designed into the overarching 
representation of the functional architecture.

---