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)



Write requirements as if the reader is a toddler

Ok, what’s this all about? You probably know by now that I am nagging you about the need to understand why it’s super important to make it right (or as right as possible) from the start. My unacademic sketch below want to illustrate just this idea.

The basic concept regardless if we talk about traditional water fall, scrum or other agile development models. Someone is trying to identify a need from an identified customer or market, interpret and expresses this in some way (textual requirements or through models) so that we can validate the information with the Customer and pass this information from a smaller group of engineers to a larger. Now a system solution is created that will capture those expressed needs so that we can start to design and build. If everything goes well, we just have to test all the requirements against their test cases and the hand over to the customer, on time and within budget. We have of cause within the project had reviews, user group meetings and functioning change- and risk processes so that everything is under control.

failed requirements process - Page 1

Voilà! That was fun. Everyone happy?!

What!! The Customer is not happy and the solution doesn’t work as it was supposed to. Now the process starts to try to fix things. The project tries to convince the customer that these complaints can be fixed with new releases of the SW and some HW changes. With increased frustration times passes and eventually the Customer says; No, now it’s enough! I want money back or I will be forced to cancel the project and take legal actions.

Of cause, I must simplify things but we have all worked in those “doomed” projects, right?!

I had the pleasure to listen to yet another study on failed projects. It was presented by Dr. Gina Guillaume-Joseph who studied over 200 failed projects with a total value of 15 billion dollars in sunken cost. I was not surprised by the result. The main reason for project failure was ranked like this:

Project failure factor Odds of project failure
Project Schedule Delays 78,6%
Changing or Unclear Requirements 29,9%
Project Failure in Test Phase 11,4%

(Source: Improving Software Project Outcomes Through Predictive Analytics, ENGINEERING MANAGEMENT REVIEW, 2015)

What can we see from this? Well first that I´m right! Customers loses faith and cancels the projects after some time and we also see problems with changing requirements and failed tests.

So, what can be done then? WHY NOT WRITE BETTER REQUIREMENTS! It’s not magic and we just have to make sure that the requirements are correctly formulated and that the sets of requirements are complete and consistent.

I want to promote the organization of INCOSE who has developed a set of rules for writing high quality requirements (http://www.incose.org/ProductsPublications/techpublications/GuideRequirements). Their guide includes about 50 different quality metrics and it’s a little more complex than the old SMART rule you might be aware of? Unfortunately, these are only available to members of INCOSE. But Imagine if you could get help in formulating good requirements which is so specific, measurable, accepted, realistic and true as its practically possible.

Since we people who are supposed to read and understand the information, we need to write information which is understandable for everyone, right? At least to the supposed reader? So even if the reader isn´t a toddler, we need to think of them as fairly “stupid”, or we will miss those obvious things, at least to us as technical experts…

I will next week start to look at the different quality metrics I mentioned above, one at a time. I will look at them and give examples and some practical tips to everyone interested. We all need to understand that this is both important, difficult, but 100% neccesary!

If you want to know more or look at some cool tools that will help you to write super good requirements, you can always look at my webpage: www.requalify.se or send me an e-mail to christer.froling@requalify.se

See you out there!



Why are people brilliant and stupid at the same time?


Why that grumpy attitude?

I don’t know if you have asked yourself that question before as in my heading, but I have from time to time. Right now, I am trailing down the path of Requirements and Information quality and I start to truly understand the concepts of Knowledge Engineering through the work I´m doing with my colleagues at the Reuse Company in Spain.

But I can again get that familiar feeling of frustration. You know this is good for you, you know it would help, but you won’t do anything about it?

Organizational resistance to CHANGE

I have led a couple of change journeys through my career and they have certainly been interesting and challenging. Above all, they have behaved differently when I look at them. The “easy” task of a new tool implementation became a nightmare and the “hard” task of reorganizing and change old work practices were dead easy. I have learnt that it’s hard to predict human behavior and impossible to predict an organizational behavior when it comes to how new ideas are accepted and the need for change is perceived and embraced.

Luckily (or stupidly) I am quite hardheaded and I just won’t give up. “I know I´m right and I will show you all that I am!”.

Some theory behind CHANGE

Have your heard about the change formula? It was developed by a guy called Gleicher in the 70th and has been frequently used since to measure change resistance in an organization. I mean how an organization perceives and react to change. The model has been developed throughout the years and I´m currently using the one by Dannemiller, et.al:


D = Dissatisfaction with how things are now;

V = Vision of what is possible;

F = First, concrete steps that can be taken towards the vision.

If the product of these three factors is greater than R = Resistance, things will start to happen.

So, this model says that if an organization is angry or dissatisfied enough, gets a clear vision of the brighter future (for them personally I might add) and have trust in their leaders who believe in the new idea and points out the next new step, the organization will probably start to move towards the vision.

Cool, right?

The truth (from the viewpoint where I´m sitting anyway)

Right now, when I´m busy saving the engineering world with some cool stuff that will help engineers and organizations to improve their information quality in both their requirements and engineering models I feel that familiar notion of suspicion and doubtfulness from the people I meet and that’s fine. I can talk about the increased efficiency and effectiveness, the increase throughput, the lowered engineering effort, the decreased time to market, the lowered technical risk, and the better product quality received, for hours and hours to really clever people.

They all usually nod their heads and become really impressed about what I´m showing and then, when I start to zoom in on the way forward moment, they get that distant shimmer in their eyes and start to mumble about how much they have to do, how their resources are constrained, there need to cut cost and they often end up using the phrase; “This was really interesting. We will have this in mind for the future…”. The wait-and-see moment has arrived and I know that they just closed the door to the opportunity they’d witnessed.

My good! It’s like me coming to a chef in his kitchen, showing that it’s better to whisk the eggs with an electric mixer than the fork he uses just right now. His response is to nod his head, and say; “Yes, that’s really going to help me, but I am too busy right now. Come back when I´m done”.


So, what’s the problem then? When it comes to writing requirements basically all organizations know that they are no good, or at least not so great. If we then add the task to make sure that requirements in natural language (on the problem side) and UML/SYSML models (on the solution side) tell the same story (over time) in a project, we all know they don´t succeed at all, am I not right?!

But (here comes the punchline), they are often TO BUSY to want to look at new solutions that would do magic for them. They are stuck in a feeling of having too much to do and the notion of someone breathing down their necks shouting, “faster, better, cheaper”!

All successful organizations probably manage this “whirlwind of busyness” quite effectively. They have created and adjusted their whole organization around it. They have created efficient workarounds and late fixes to overcome the real problems and the root cause to them. They streamline their processes for engineering change management, they implement continuous integration practices, they implement automatic SW builds and testing, they become experts on risk management and builds effective project organizations to keep the speed up.

They are not seeing the problems any more, they are now basically cumbersome facts of life and they continue to steer that big ship with great(er) speed toward that huge ice berg called “the future”!

We should not forget that these organizations probably also have great “engineering heroes” that saves the day in the most doomed engineering efforts. These people are the ones getting the official gratitude of success, the financial compensation to do so and the glory, so why should they change a winning concept? Everybody is happy, right? But they probably don’t realize that they at the same time destroy more than they fix for the organization as a hole.

So, even if the dissatisfaction is high in the organization (HR sees it every year in the company staff survey) and I can show them those basic steps that needs to be taken, the vision becomes an unreachable nirvana and nothing happens because of the itching “feeling of being to busy”. But imagine the result by using an electric mixer instead of that fork to those eggs?! My good, when that potential is finally released!

The end of all work practice innovation?

Luckily for me there are not only “just clever people” out there, there are also people (leaders) that can embrace the vision, understand the potential and start that journey (even if they too are very busy). Requirements Engineering and perhaps Systems Engineering practices are dying (hard words) as we know them today. Soon it will be all about Knowledge Engineering, mark my words for it!

Basically, it’s because speed in technological innovation and both system- and business complexity increases exponentially and we need new and more flexible ways of managing complex system-of-systems engineering in the future with these AI, cloud-based and distributed systems and organizations.

fly off

Organizations (and people) that don´t value its intangible knowledge as their most valuable asset and embrace the need for constant change will disappear quietly in the fog of the past. The future lays ahead those organization what triumph WITHOUT those engineering heroes and who manages their knowledge assets to create, maintain and develops them over time. The right information, to the right person at the right time, that’s the foundation for happy, efficient and innovative originations.

My question is really: “Will you and your organization walk in the shadows or come out and play in the sun”?

That’s all for this time. If you want to know more about knowledge engineering, information quality or just want to chat (or debate), contact me at christer.froling@requalify.se or visit:

Next time I will look more into the concept of MBSE (I hope to get some cool guys experts comments) and I´m thinking about starting some shorter requirements quality lessons. That’s quality in requirements development, really? How SMART are we?


Requirement as we know them are dead. They were killed by Models, or…?

Today I had the great privilege to eat lunch with professor Juan Ilorens, also the CEO of a company on the technical forefront, The Reuse Company. They work with natural language processing, requirements quality and information reuse.

Juan llorens, CEO The Reuse Company

I tried to provoke him by asking: “Do you think the written requirement as we know them are doomed to disappear by the increased use of different modelling techniques? Everybody today seems to talk about Model Based Systems Engineering, MBSE, as the future of Systems Engineering.”

He stopped eating and looked at me with his typical smile and said: “The challenge for a modern Systems Engineering organization today is to know how to manage their knowledge. When we have tested the level of understanding we see that people tend to understand text better than a plain model without any text in it.”

We must remember that requirements as well as models are to be used to capture knowledge and design decisions to pass information downstream to the persons in need of that information. The goal for many organizations today of using exclusively models to capture this kind of knowledge will simply not work. The different stakeholders don´t have the same levels of modelling skills and will not truly understand what they see”.

But isn’t models any good, I asked?

“Yes, models have obviously benefits if you use them correctly and in the right way. The tendency today is basically “all or nothing” and that’s wrong. Models are good for automatic processing, simulation, analysis, code development, test case development, etc. But today the MBSE community says that models are great for stakeholder communication and I believe this is just wrong or deeply exaggerated”.

Juan continued: “We assume that an organization understand the modelling notation just as good as natural language like English, but we have learned to interpret models later in life at university or later and theoretically it works to communicate through models, but in real life it doesn’t.

Engineering today seems to be a fight against complexity and in order to defeat it we introduce modelling as the universal medicine solving every issue for everyone. It’s just about adding views and diagrams and we can manage every need. But we are creating monster models that way. Today’s technology and systems are so complex that we more than ever need communication between different groups of people and that communication is reduced by models not the other way around.

Engineering is to communicate and agree on different things and we work in teams, often distributed. We need a way of working that maintains the information and knowledge over time. I think this needs requirements written in natural language and we need traceability between different knowledge assets. Our notion in the Reuse Company that engineering teams needs help in analyzing correctness, completeness and consistency of different knowledge assets like requirements and specifications will soon be expanded to include even models. Imagine comparing a System Specification with a System Model to find errors like inconsistency or incompleteness. That will truly mean a revolution for engineering! That’s why we today have started to talk about Knowledge Engineering at Reuse.”

So, Juan. You mean that Requirements written in plan and natural text will co-exist with models in the future and not become replaced by them?

“Yes absolutely. When we help people to write high quality requirements using structured techniques like patterns we can start to build powerful reasoning around the requirements themselves. If we also add the possibility to compare them against other assets like models we will become super effective and much smarter than today. We will soon release methods and tools that handles this. We are talking about an engineering knowledge revolution my friend”.

Now it was time to say goodbye after an extremely nice and interesting lunch. I can’t wait to see what Juan has up his sleeve. Next post will be on MBSE. I need to look more into what is said out there about this subject. But I am now more than ever convinced that requirements are here to stay. If we speak to one another using natural language, we will need to capture the different stakeholder needs with natural language requirements. But we shall use modelling as a complimentary technique to manage complexity, make simulations and other cool stuff. Requirements are here to stay, mark my words for it.


Assumptions over time becomes facts…

Last week I visited a good event arranged by INCOSE Denmark. It was a training workshop held by Colin Hood called “Understanding Requirements”.

The day was filled with theoretical lectures, but mainly different exercises on how to interpret information. It was fun to work in groups and we all soon realized that it is difficult, very difficult, to make the right conclusions and understand the true intention of both written text and/or graphs/models.

It did not matter if we looked at the basic text (requirements) and draw a sequence diagram or if we used a diagram to understand the “true” meaning. We soon got trapped in our own minds with its limitations, presumptions and way of making quick conclusions to fill in the blanks. If we believe in the idea strongly enough or just hear it multiple times it soon gets cemented as a fact.

It was impressive to see so much clever engineers doing so many collective mistakes. And yes by all means you learn by the mistakes, but as Colin said: “Assumptions over time becomes fact” and we all got terribly blind during the day.

Those mistakes done in real projects will cost so much money and create rework and bad-will for the company and brand. Colin showed one simple example with a small button on a washing machine causing the company in question to make extensive product recalls to fix the problem.

I am therefor convinced that tools like the Requirements Quality Suite (RQS) is a great help in assessing both basic textual quality to make each single requirements SMART (yes, that old saying), i.e. that they are correct, but also to get help to analyse the complete set of information to see if its consistent and complete.

Take a further look at the tools here: www.requalify.se or just give me a call or e-mail.

And thanks again Colin Hood for a good lesson learnt.