This presentation was created for the SATURN conference series and does not necessarily reflect the positions and views of the Software Engineering Institute.

This presentation will discuss how SEI Attribute-Driven Design (ADD) was employed to develop a framework that was employed as a basis to develop the software architecture of a complex large-scale control system in a multinational organization. The emphasis of this presentation will be on describing details of the process that was followed to define composite critical scenarios that were employed to define the software architecture. The project was quite challenging as it had several unique characteristics. First, the product development unit is geographically dispersed, and for this reason the business managers, architects, and development team were not located in the same geographic region. Second, there was an obvious disagreement among the stakeholders in the business unit regarding business goals, priorities, functionality, and software quality attributes. Third, the business unit already had several competing products that were maintained using different noncompatible technologies, and therefore members of each product group had strong biases towards their own technology. The authors will discuss how the above challenges were addressed to create a critical scenario framework that was agreed upon by all parties. This framework extended the ADD methodology by clustering ADD scenarios into themes that described the system-critical scenarios. The presentation will describe how the organization’s business goals were defined and collected in geographically distributed workshops. Due to the large divergence in opinions, a voting mechanism was employed to define and prioritize the business goals. Market requirements were collected to define the primary functionality of the system. Details will be provided on the method used to collect and document these requirements. Using the set of prioritized business drivers, the software qualities of the large-scale system were defined. Using the software qualities and also the market requirements, the system’s critical scenarios were defined. These critical scenarios are described by common functionality themes defined by the market requirements, and a set of nonfunctional requirements defined by the software qualities. To make the system-critical scenarios useful, nonfunctional requirements need to be quantified. As the same nonfunctional requirement can be employed in several critical scenarios, the functionality theme provides a context under which the nonfunctional requirements are given a value. This presentation will discuss in detail this process and provide examples for the audience.

PDF [404 KB]

PRESENTATION