Part 5 – Decisions, trade-offs and architectural requirements


In previous posts Hillary has discussed Steps 1-5 of the “six step process” and we have now come to the end of the staircase. It has been so interesting to read how the architecture evolve and let’s not waste any more time introducing this chapter. Here is the final chapter from Hillary Sillito on the subject of; “What has system architecture got to do with requirements?”

A shared mental model

I have discussed the different steps in the “six step process” and have described the steps sequentially, but really there’s a lot of iteration and going back and forth. It’s a learning process – we work on each step in turn to increase our understanding of the whole. The first time through, we go as quickly as possible to build a coherent skeleton. Then we’ll flesh it out as needed to support decisions and give everyone a good understanding of the whole system and how their bit fits in.

A very important aspect of architecture is to give the team a “shared mental model”, so that “everyone is making the same system”.


Equally important, the six steps of system architecture show us how the different perspective are linked, and let us do trade-offs across all the perspectives to make the system cheaper, simpler and more effective.

The physical parts need to be chosen so that they fit together and work together. The individual physical parts that best fit together might not work together so well in “rainy day” scenarios. The parts that work together best for the “rainy day” scenarios might be too big, or take too much power. This is where we get the payback for all that work we did on enterprise and operational perspectives. Maybe we can make the system better, or cheaper, or more reliable, or easier to use, or all of these, if we go back up to Step 2 and change the way the system will be used.

The six step architecting process opens up the range of possible choices and lets us trade not just within the technical solution, but between the technical solution and the operational concept. It might be cheaper to change the way people work than to add complexity to the new product – or maybe we don’t even need the new product at all! Requirements can be renegotiated if we can show, through the architecture, how they make the solution expensive and risky.Hillary_part5

But hold on. I said six steps, and we’ve only talked about five. What is step six? That’s the decision perspective. Each of the other five perspectives involves a set of decisions; but since the perspectives are all inter-linked, we need a holistic view of how decisions interact and have consequences across all the perspectives.

The Decision perspective

Decision structures can be complex. One decision drives another, which drives another, which drives others, which drive the first. Or we have a long decision tree with many branches. So that the work can be planned in a good sequence, we need to build a decision map, which shows us how the key decisions relating to the architecture are inter-related, what order they should be taken in, and what supporting analysis and experimentation is needed to inform each decision.

This brings us to architectural requirements. When we architect a system, we combine knowledge from the problem space of what the customer wants, with knowledge from the solution space of how the system needs to be constructed to work, to keep working, and to be no more costly than absolutely necessary. One of the key architecting roles is to make the system-wide design decisions that impose coherence, consistency and efficiency across the system. These might be design principles for safety and security, common interface and data definition standards, overall power and thermal management, consistent layering schema, consistent start-up and recovery strategies, common MMI look and feel, standardised personnel and training policies, whatever is important for the system of interest.

All these decisions are to meet the implicit customer need for an effective system that is fit for purpose; but most won’t be traceable to explicit requirements in any straightforward way. The requirements management process needs to capture the rationale for the system wide design decisions and ensure they are reflected as requirements on the subsystems.

Previous post in this series on Architecture

This post is part of a series on architecture 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

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

Part 4: Part 4 – System Architecture Provides the framework and rationale for allocating requirements to parts

About the author

If any of you have the urge to get into contact with Hillary Sillitto he can be reached through his web page: www.sillittoenterprises.com

Next Blog

This was (sorry to say) the last post made by Hillary on this topic. I wish him to come back and write more! Next time I have another great mind who is going to elaborate about the errors and problems with User-Stories…

See you next time!




Part 4 – System Architecture Provides the framework and rationale for allocating requirements to parts


What has system architecture got to do with requirements? This was the first question in this series written by Hillary Sillitto. We have since then read about how an architecture may be used to address requirements coherence and completeness. Its now time to move on to the next step in Hillary’s six step approach to system architecting.

Going from black box to glass box

Now we get to what most people think of as the main point of system architecture, the logical and physical “glass box” views of the system. These are steps 4 and 5 in our six step process.


It’s very tempting to jump straight into the physical solution, because we usually have preconceived notions about how the system should be constructed. But if we do that, we’ll probably just do it the same way we always did. Often there is a cheaper, or better, or smaller, or more reliable way of doing part of the system; or the part you intended to use is no longer available; or the supplier put the price up and you need to look at alternatives. If any of these happens, and we didn’t do the architecture properly, we’ll find we can’t separate out the requirements for the bit we’re replacing, so we have to do the complete requirements allocation again from scratch.

That’s why we do the internal architecture from two quite distinct viewpoints: the logical perspective, where we think of the system as a network of interacting processes or sub-functions; and the physical perspective, where we think of the system as a set of interconnected parts.

We break each system function down into a set of sub-functions or internal processes. The sub-functions are broken down or “decomposed” just enough to allocate them to a conceptually feasible “design element” – which could be a bit of hardware, or software, or a process, or operator task. The sub-functions and the flows between them form a “process thread” running through the system from input to output – like the mission threads we developed in Step 2, but this time inside the black box. The requirements for the function are then decomposed so they can be allocated to the sub-functions.

Then we choose appropriate specific solutions for implementing each sub-function, and work out the best way to group these design elements into an efficient set of “physical” parts. (In this context, the “physical” architecture includes software and processes and people and organisations, not just hardware.) The requirements for a part are just the requirements for the sub-functions allocated to it, and a share of the physical budgets for space, weight, power, etc. You can think of this as “allocating bundles of functionality, with the accompanying bundle of requirements” to the physical part.


To summarise: the logical architecture provides a framework for flowing down the functional, behavioural and performance requirements; the physical architecture provides a framework for flowing down the physical attributes and characteristics; and the allocation of logical to physical components completes the flowdown of requirements from one level in the system hierarchy to the next.

When we’ve completed this step in the architecture, each part will have its own set of black-box requirements – functions, performance, behaviour, states and modes, and physical characteristics.

This all sounds a bit over-analysed. But the payoff comes when we have to change something. Suppose we get some whizzy new technology that lets us consolidate two parts into one, or we need to change the logical-to-physical mapping to satisfy some speciality engineering constraint. We need to do a lot of work to re-specify the parts if we don’t have the logic for what each part does and why. But if we have already done a decent job of the logical architecture, we don’t have to re-engineer the requirements from scratch; we just allocate the relevant sub-functions to a new set of physical parts, and the requirements go with them. We can make precisely-targeted changes to parts of the system without having to rethink the whole system.

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

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

Next post in this series

Next post will be the last of this series by Hillary Sillito. Then he will discuss decisions, trade-offs and architectural requirements. I can´t wait!

See you then!


People don´t understand or listen properly to me. Should I be mad?

My Webex extravaganza…

Last week I had the opportunity to host a Webex with the provocative title “Start over and do it right! The art of writing high quality requirements”.

It went super and the audience listen to me talking about human behavior, the art to write a statement in natural language that is clear, correct, complete and consistent within its context. I did not ONCE talk about how you go about and develop the System solution, but I did the “mistake” of showing that your goal is to go from A (a user need) to B (a System that fulfills A) with a time lime between. So, I got feedback stating:

“This is waterfall and that’s not very Lean. I expected to hear something new”.

Or what I think is the best comment of them all:

“The presenter stated that you shall write the requirement in the beginning and that’s not Agile. We do many short sprints in my project and do not need to spend useless time in the beginning on writing requirements that no one reads anyway. We focus on the customer instead”.


For me the above feedback given to me shows that:

  1. People are still in the Waterfall vs. Agile development war. Why? If you use a waterfall model correctly, plan your tasks and iterate accordingly, this can be both Lean and Agile. Why have we not come further? I have heard this debate for 20 years now and it’s not taking us anywhere. Give it a rest!
  2. I did a mistake to present a straight time line (with an arrow I might add) from A to B and instantly people thought that I meant that you do thing once and you never go back, EVER? I did not once said that, so Why is the interpreted like that?

The art and science of  NPL

But again, it just proves me right in the first place.. I talked in my WebEx on human behavior and how our brain interprets information (written or spoken). There is a fascinating field of Neuro linguistic programming (NLP) that encompasses the three most influential components involved in producing human experience: neurology, language and programming. The neurological system regulates how our bodies function, language determines how we interface and communicate with other people and our programming determines the kinds of models of the world we create.


So, what happened in the WebEx? Since the body language where minimized to just showing my face, the spoken information was a one way street with no interaction with the auidience, the listeners “programming” caused problems. Even if I NEVER said the things mentioned in the feedback, the listeners clearly THOUGHT that was what I was trying to say. One of the most prominent flaws we humans have is to first fit new information into our existing (old) belief system to verify that we are still correct.

The fun thing is really that this was EXACTLY my point in the Webex! We need to be better at stating requirements in the first place (and itterate of cause) so that the reader  don’t end up having to interpret, misunderstand or read between the lines. We need requirements that are CORRECT, COMPLETE (as a set of requirements) and CONSISTENT within its environment/context.

But, I shouldn´t be that angry or hurt. The problem is still mine if I go back to the WebEx in this case. I cannot blame the audience for not understanding me. They were both as intelligent and experiences as me (ok, almost.). BUT I did not reach them with my ideas or intentions. I was not clear enough with my information and did not adopt it to audience!

And by the way. It does not matter if you write requirements in natural language or write use-cases, personas, scenarios, diagrams, drawings, SysML-models, SCRUM back logs, test cases (or even WebEx feedback to a grumpy old fart)….. The problem may occur regardless the PACKAGING of the information!

Stay tuned and for god sake. Give me some feedback!


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!


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


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.


“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.


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!


What has system architecture to do with requirements?


Have you asked yourself why requirements exist alongside the system architecture? Are they both needed, which one comes first or have precedence over the other? In this time of “debate” on the need for written system requirements in natuarl langiage vs. system models of the architecture (perhaps you heard of concepts like MBSE, SysML models..?) I thought it would be nice to go back to the root cause of everything.


Today I will start a blog series focusing on the topic of system architecture to give this blog some balance. These posts are written by Hillary Sillitto (read his bio at the end of the post) whom I met when I was leading the Scandinavian Summer School. I have had the opportunity to both listen to Hillary giving a fascinating presentation on the topic of successful systems at a Systems Engineering symposium and read his comprehensive book on architecting systems which I can recommend to anyone interested in system architecting principles.

So, without any further introduction, here is the first part of Hillary’s contribution to this blog. Enjoy!

Part 1 – The basic reasons behind a system architecture

There are at least four reasons why we need a system architecture.

First, architecture helps us discover what the requirements should be.

Second, it helps us decide if the requirements are coherent and sufficiently complete.

Third, it provides the framework and rationale for allocating requirements to the parts of the system.

And fourth, some lower level requirements don’t come directly from customer requirements but from architectural decisions. These decisions are about making sure the parts of the system, when connected to each other and placed in the operating environment:

  • fit together and work together;
  • achieve the required effect and don’t produce unacceptable side-effects;
  • can be kept operational over time, and reconfigured to meet “reasonable unforeseen” circumstances.

The best way I’ve found to understand the different aspects of architecture, and how they relate together, is what I call the “six step process”. We move up and down the “steps” to develop a complete and coherent description of the system using the complementary perspectives of the six steps. I’ll use this “staircase” as a framework to link a series of posts tackling each of the four reasons in turn, and show how they inter-relate.


Next time…

This was a short introduction and next week Hillary will start to “walk down the ladder” of the six step architechting process. Please comment or give input to this post and the blog itself. Its nice to get your feedback.

Stay tuned!


Author Bio

Hillary Sillitto is an internationally recognised expert and thought leader in systems thinking and product development engineering. Now working freelance, he is based in Edinburgh, Scotland. His website is at www.sillittoenterprises.com

Hillary Sillitto

I studied Physics at St Andrews University, and Applied Optics at Imperial College. I began my career with Ferranti in Edinburgh as an optical engineer, working first on laser system projects, led the optical design team for the UK’s first airborne multi-spectral electro-optical pod, and played a key role in developing the company’s infra-red countermeasures business. I shifted to Thales Optronics in 1993, serving as Chief Systems Engineer and Chief Engineer. Seconded to Thales UK Corporate in 2003-04 as Director Prime Contract Support, I made contributions to programmes including Soldier Systems, the Future Carrier, and UAV / C2 systems. From 2005-08 I was seconded to UK MOD as Head of Integration, responsible for managing system-of-systems interoperability. I returned to Thales to become Chief Systems Architect for the Thales Land and Joint Systems Division in the UK, and then Thales UK Systems Engineering Director, with an overview of a very wide range of complex system developments including in the transport and security sectors, and was appointed a Thales Fellow. 

I left salaried employment in 2013, since when I’ve written a book on Systems Architecting, been working part time, and contributing to INCOSE’s efforts to improve systems engineering practice. This is the third year I’ve been teaching a course at the Scandinavian Systems Engineering Summer School based on my book.

I’ve been awarded eight patents and made a number of notable contributions to the Systems Engineering literature, including “Design principles for ultra large scale systems” (Best Paper Award at the INCOSE International Symposium, Chicago 2010), “What is a system? – an ontological framework” (Dori and Sillitto,  Systems Engineering Journal, summer 2017), contributions to the BKCASE Systems Engineering Body of Knowledge, and my recent book “Architecting Systems – concepts principles and practice” (College Publications 2014). I’ve been appointed to Visiting Professorships at the Universities of Bristol and Strathclyde.

I’m a Chartered Engineer, Fellow of the Institute of Physics, Fellow of the International Council on Systems Engineering, past president of the INCOSE UK Chapter, certified Expert Systems Engineering Professional (ESEP), and am a Full Member of the Omega Alpha Association.”


Herding cats – Working with capability requirements


My friend Christer Fröling asked me to write a piece in this blog about my experiences with requirements, something insightful, something deep, and something cool.

My pick today falls in the category of requirements, which many System projects, in particular IT systems, fail to see, despite of the obvious. I will dedicate this short session to Capability Requirements, and role of Validation as a driver for delivering them.


My name is Sam Lund, and I am a capability addict. You can check more about me at www.stellapolaris.co

Business Requirements: easier said than done

Business requirements represent a contract between the parties, the customer vs the supplier, and provide unambiguity in their expression on what is the expected outcome, and also identify who or what shall act on the requirement.

However, the serenity of this thought does not remain too long, when trouble already sneaks in. Where Business Requirements succeed in describing expectations, they give little or no credence to how it all should take form at the supplier. And very often, there is a large gap to the reality at products and systems as their developers see them.

When it all should be put into action – delivering it – there are range of circumstances which suddenly start to erode the whole delivery process. There are supporting elements, which ought to be included, but were too distant of an idea, when the planning was conducted. There are services which should have been created, and which now would be needed in the delivery, but even those seem to have been missed.

Simply put – organization lacks the Capabilities needed to successfully cover all the elements of the contract.

The hidden factor: Capability Requirements

You cannot solve Business Requirements correctly, if not analyzing all the contributing elements required to solve them. Some of these contributing elements are defined by direct needs and some of them are emerging through in-direct, supporting elements and enabling pre-requisites.

Only when combined, when you apply those elements together – you create a “Capability”. It can be one, or multiple capabilities, which are needed in order to resolve a Business Requirement. And most of the times, this is more than just the technical system. It tends to include processes, organization, documentation, training, support organization and information.

A vehicle will very quickly end being a useful transport, if it lacks gas stations for fuel, maintenance and service, reserve parts, organization, tools, manuals, guidelines…

And all of those identified contributors – will be subject of requirements too! Capability requirements. These align all the contributing factors, with specific requirements and their expected effect levels (acceptance criteria) to create the ultimate expected outcome. When all of these capability requirements are delivered – a capability is born. And to drive this delivery – you need Tasks.

As you execute and complete Tasks, requirements get fulfilled, and eventually a pattern starts to emerge of a System or Element of it, and for which, a level of performance may become verifiable.


Creating Coherence – integration in performance and time

Creating a Capability is an integration effort. Apart from verifying various systems and technical elements, the integration includes also verifying and integrating the intended operational processes (concept of operations), support processes, training requirements, competence requirements, etc. Everything which makes the Capability. And it might be, you need to setup and evaluate operations, so that even these rise to the level of the expectations.

Once every piece clears out, and integrates consistently in time and performance, you can evaluate that the joint effect of this integration – actually delivers the intended outcome, the capability and its effect. This continued integrated delivery of performance, is often called Coherence.

And it is now, you can finally start to Validate, that the solution meets the business requirement. I.e. what is the performance level of the Coherence achievable, and will this meet the acceptance criteria of the Business Requirement.

Victory in Validation

And this, my friends here reading this blog, is the ultimate difference between Verification and Validation.

It is Validation which finally confirms the coherent delivery of the performance and effect. And this validation process can actually be much more than just a final judgement towards customer delivery. It can also be a continuous process of coherence assessment, of behavioral standards of the total System (of systems), in particular when working with operational solutions.

When evolved towards that end, Validation can become much more than just an assurance function. It can assume a continuous role, and an essential part in managing operational delivery of the Capability.

To think about

how much of these Capabilities would appear to be really “new” for any IT system? The actual structure where capabilities are expressed, should be rather stabile for many types of organizations and applications. Variations are rather in the level of requirements and their target performance levels.

Having Capability Structures, expressing current state of affairs, would then streamline Business interaction, and reduce commercial and technical project risk.

To be continued…

Inspiring as always Sam! I will end with a quote I love and next time I will post the first blog about some of the rules you might want to stick to and some advice on how to write good, high quality, requirements. Don´t forgett to contact me with ANY question you might have or suggestion for topics to bring up!

“One of the most dangerous forms of human error is forgetting what one is trying to achieve.” – Paul Nitze (1907–2006)