Uncategorized

Part 2 – Using System architecture to Discover what the requirements should be.

Introduction

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 continue with the first steps down the ladder taking about enterprise and operational needs.

System requirements don’t appear by magic.

They’re developed from stakeholder needs, and by understanding how the system will be used in its operational context to produce the desired effects. To do this, we work on Steps 1 and 2, the Enterprise and Operational Perspectives.

Hillary_part2

“Who cares, and why?” is the question we answer with Step 1, the enterprise perspective. This is about identifying the stakeholders, what their concerns are, and which parts of the system lifecycle they’re involved in.

This helps us organise the stakeholder requirements, understand which apply to each lifecycle phase, and identify who needs to be involved when requirements are in conflict and we need to negotiate a compromise. The outputs of this “step” are the stakeholder map, and the agreed purpose, context and measures of effectiveness for the system.

“How will the system be used?” is the question addressed by Step 2, the operational perspective. The answer gives us the context for requirements, so we can interpret them properly.

To develop the operational perspective we look at a series of “mission threads”, which describe the end to end user experience involving our system.

Why “end to end”? Surely, we’re only interested in the inputs and outputs of our system? But first we need to work out what these should be! To do that, we need to understand how the system will interact with its wider environment, its “operational context”. And if we want to give the best possible customer experience, these interactions need to be as seamless as possible. To achieve this, we need an end-to-end understanding of the typical “customer journeys” or “mission threads” our system is involved in.

If our system is an airport, we might think the boundary is the airport perimeter. But for the passenger, the user experience starts with planning the trip, checking timetables and booking the flight; and it doesn’t finish til they’re at the destination, and perhaps only when they have filed their expense claim and paid their credit card bill. If we understand this whole journey, we’ll design a better, and better-connected, airport.

And then there are a whole lot of other important “mission threads” for other stakeholders. How do the airport staff get into work in time to greet the first passengers? How do the crew get to the plane, and sort out their flight plan? Where do taxis go after dropping off the passenger, and where do they wait til they can come in and pick up another fare? This collection of mission threads forms the basis of what is often referred to as the “operational concept” or “concept of use” for the system, and is the basis for working out the key requirements and performance measures.

airport-design

The concept of use also answers some very important, more detailed, questions about the requirements. Which requirements need to be met simultaneously, which could be covered by different system states or configurations, or at different lifecycle stages? A plane only needs to have its undercarriage down when it’s on the ground; we may only need to connect to test equipment in maintenance mode; recycling requirements need to be satisfied at the end of life. We need to understand the degree of concurrency – how many simultaneous users, how many simultaneous threats might the system have to deal with? How quickly do we need to switch between one state and another? Which external systems does our system have to interface to, and why? Do all the interfaces need to be active at the same time, or can we switch between 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 post or his personal bio here:

Part 1: https://requirementdoctor.blog/2017/08/17/what-has-system-architecture-to-do-with-requirements/

Next post in this series

Next post will continue to discover the relations between architecture and requirements and focus on the system itself..

See you then!

2 thoughts on “

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