Part 3 – Using System architecture to Decide if the requirements are coherent and sufficiently complete


What has system architecture got to do with requirements? This was the first question in this series written by Hillary Sillitto. This time he will discuss how the architecture itself can help in the difficult task of knowing when you have a complete set of requirements.

How to know when you are “sufficiently complete”?

In the last post, we talked about using Steps 1 and 2 of the six-step systems architecting process to understand “what the requirements should be”. To make sure the set of requirements is coherent and “sufficiently complete”, we need to work between steps 2 and 3, the Operational and System perspectives, until everything ties up.


To complete Step 2, we weave all those mission threads together into a tapestry that we can think of as “a day in the life of the system”. This describes all the things that might happen in a typical, or not-so-typical, day of the system’s operation. Things sometimes go wrong, and the user experience is radically influenced by how the system copes with these “rainy day scenarios”.

We look for “simplicity through the complexity”, for common repeating patterns in the mission threads, so that we don’t generate new requirements for each mission thread, but find a common set of requirements that allows all relevant mission threads to be satisfied. We’ve probably finished the operational architecture when we can add more relevant mission threads and don’t find any more requirements.

In Step 3, the system perspective, we view the system as a “black box”.  The first thing we need to do in the system perspective is to choose where to put the “responsibility boundary” of the system. Where to put this “outside surface of the black box” is guided by how easy it is to define the interfaces. The architecting heuristic (rule of thumb) of “high internal cohesion, low external coupling” is a good one to apply.

OpenSystemRepresentation.svg(source Wikipedia)

Depending on how we chose the system boundary, we might need to specify the system as a product (e.g. a cash machine), or as a service (e.g. the service of providing cash), or in terms of the capability it provides (e.g. the ability to offer a range of secure and dependable banking services). Depending on this choice, we’ll need to write the requirements differently.

We should specify the requirements for the system in a way that can be tested at the boundary and doesn’t make any assumptions about its internal design (remember, it’s a “black box”), so that we don’t pre-empt design choices and unintentionally exclude solution options. We need to think about how the system will satisfy all the use cases contained in the mission threads. We need to define the functions of the system, how well they need to be done (performance), under what operational conditions, and in response to what inputs (behaviour).

The external system interactions we identified from the mission threads in Step 2 need to be supported by appropriate interfaces. What throughput (flows of material, energy and information) do these interfaces need to support, in what operational conditions? If any interfaces are asked for that don’t seem to be involved in any of the mission threads, have we missed an important mission thread? Or is the interface not needed?

The concurrency we looked at in the operational perspective helps us choose the states and modes for the system. States and modes provide a good framework for organising the requirements, and for identifying those which need to be met all the time, and those which only need to be met in some modes, configurations or situations.

And then we need to specify the physical requirements for the system to be usable in the intended operational environment. A requirement for the new British aircraft carriers was to be able to pass under the Forth Bridges, while Portsmouth Dockyard needed to be modified to accommodate them.

Previous post in this series on Architecture

This post is part of a series on architecure and requirements by Hillary Sillitto. You can read the previous posts or his personal bio here:

Part 1: what-has-system-architecture-to-do-with-requirements?

Part 2: System requirements don’t appear by magic

Next post in this series

Next post will continue to discover the relations between architecture and requirements and focus on the rational and allocation of requirements.

See you then!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s