Page 160 - Software and Systems Requirements Engineering in Practice

126 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

ichael was assigned as a software architect on a project to
develop a building security management system. He knew
Mthat he would start this assignment by talking to the
requirements engineers, review the requirements in the database,
and become familiar with the operation of some similar products
developed by his company and its competitors. He planned to learn
enough about what the new product would do to be able to propose
a draft architecture for efficiently meeting the requirements.
He began reviewing the functional requirements that had already
been described in the requirements management database and the
high-level use cases and scenarios that had been developed. He
quickly realized that the architecture would need to be able to meet a
large number of nonfunctional or quality attribute requirements.
These requirements often were described with a word with “ity” at
the end of it, e.g., security, scalability, maintainability. But, the areas
Michael became most concerned about were performance and
reliability. Since a security event can generate a building alarm, he
began to worry about how long it would take after the event occurred
for security personnel to be notified. He could imagine many bad
outcomes if the security system that he was designing was too slow
or unreliable in notifying personnel of the event. As a result, he
considered architectural approaches for a system that would respond
quickly and reliably to events.
This chapter deals with nonfunctional or quality attribute
requirements: their elicitation, analysis, validation, and management.
While these requirements are deemed architecturally significant, they
must be treated with functional requirements in an integrated manner.
A conceptual framework for an integrated approach is described
along with its application to an industrial case study.

5.1 Why Architectural Requirements Are Different
Software architecture is defined as “a structure or structures of a
system which comprise its software elements, their externally visible
properties and relationships among them” [Bass et al. 2003]. Some
of the structures consist of static software elements such as classes
or modules that are related to each other through inheritance or
decomposition. Others include runtime structures, consisting of
dynamic software elements such as processes or tasks related to each
other by data transmission or invocation. Architecture is concerned
with the public interfaces via which these elements interact and the
externally visible properties of these elements and their interfaces.
The requirements that drive a product’s architecture are often
quite different from the requirements that define the functionality of
a product.