Page 230 - DCAP405_SOFTWARE_ENGINEERING

Unit 13: Building the Analysis Model

Notes

Notes In almost all cases, it is useful to start by building a model of the software context.
The software context provides a connection between the intended software and its external
environment. This is crucial to understanding the software’s context in its operational
environment and to identifying its interfaces with the environment.
The matter of modeling is tightly coupled with that of methods. For practical purposes, a
method is a notation (or set of notations) supported by a process which guides the application of
the notations. There is little empirical proof to support claims for the superiority of one notation
over another. However, the widespread acceptance of a exacting method or notation can lead to
beneficial industry-wide pooling of skills and knowledge. This is currently the situation with
the UML (Unified Modeling Language). Formal modeling using notations based on discrete
mathematics, and which are traceable to logical reasoning, have made an impact in some
specialized domains. These may be imposed by customers or standards or may offer compelling
advantages to the analysis of certain critical functions or components.

Architectural Design and Requirements Allocation

Sometime, the architecture of the solution must be derived. Architectural design is the point at
which the requirements process overlaps with software or systems design and illustrates how
impossible it is to cleanly decouple the two tasks. This topic is intimately related to the Software
Structure and Architecture subarea in the Software Design KA. In many cases, the software
engineer acts as software architect because the process of analyzing and elaborating the
requirements demands that the components that will be responsible for satisfying the
requirements be identified. This is requirements allocation–the assignment, to components, of
the responsibility for satisfying requirements.
Allocation is significant to permit detailed analysis of requirements. Hence, for example, once
a set of requirements has been allocated to a component, the individual requirements can be
further analyzed to discover further requirements on how the component needs to interact with
other components in order to satisfy the allocated requirements. In large projects, allocation
stimulates a new round of analysis for each subsystem.

Architectural design is closely recognized with conceptual modeling. The mapping from real-
world domain entities to software components is not always obvious, so architectural design is
identified as a separate topic.

Task Analyze how the requirements of notations and methods are broadly the same for
both conceptual modeling and architectural design.

Requirements Negotiation

Another term usually used for this sub-topic is “conflict resolution.” This concerns resolving
problems with requirements where conflicts occur between two stakeholders requiring mutually
incompatible features, between requirements and resources, or between functional and non-
functional requirements. In most cases, it is foolish for the software engineer to make a unilateral
decision, and so it becomes necessary to consult with the stakeholder(s) to reach a consensus on
an appropriate trade-off. It is often important for contractual reasons that such decisions be
traceable back to the customer. We have classified this as a software requirements analysis topic
because problems emerge as the result of analysis. However, a strong case can also be made for
considering it a requirements validation topic.

LOVELY PROFESSIONAL UNIVERSITY 223