SASSY – Analysis, Part 3

Requirements

The requirements for a system come in three categories: Functional, Environmental, and Quality.

The functional requirements describe what the system is required to do.

The environmental requirements are usually restrictions that the system must conform to, such as the operating system that must be used, or that the software will be for medical use.

The quality requirements describe those other aspects of the system, such as performance, safety, usability and maintainability.

Tactics

The components of a system have a set of responsibilities. Each component has assigned to it a set of things that it is responsible for.

For the functional requirements these normally map directly to a component’s responsibilities. That is, a particular component will be responsible for a particular system function.

For the quality requirements however there is no single component that is directly responsible. No component could be responsible entirely for the performance of the system. A tactic is what maps these requirements to a set of responsibilities which can then be assigned to components. For example a scalability requirement might be met by using a client-server design – the tactic. We can then map the consequential responsibilities to components; in this case by putting a service in one component and a client in another, and perhaps a name lookup service in a third.

Thus the design process is one of selecting a set of tactics that give the best response to each of the quality requirements. Of course there will be competition since using one tactic might compromise the use of another – it is hard to have a system that has both good security and good usability, for example.

In their introduction to tactics Bass, Clements and Kazman define a tactic as a design decision that influences the control of a quality attribute response. They also define an architectural strategy as the collection of tactics, and an architectural pattern as something which packages one or more tactics.

The software architecture ontology that will form the foundations for SASSY should include a collection of well known tactics and their relationships to the quality attributes.

Alternative Requirements

While considering some potentially very large systems it became apparent that sometimes the requirements were not always single valued. For example, building a system to support an entire organisation might have an environmental requirement that the solution must use Microsoft products where possible. However we can easily imagine a similar project that had a requirement for open source software where possible. The conceptual architecture for these two alternatives is likely to by almost identical, with the differences appearing in the logical and execution architectures.

Similarly the same project – a system to support an entire organisation – might be required to support a small office, a one-man company, or a large government department. When you look at the functionality, a lot of the requirements are identical but the quality requirement of scale has various alternatives. Again the conceptual design is likely to be quite consistent across all scales, but the logical and execution architectures will diverge.

It would seem then that the design of SASSY should include the capability of creating a suite of alternative designs based on these varying requirements.

It is somewhat amazing that we have gone from systems that are gigantic in scope to suites of such systems !


This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.