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

5 thoughts on “What has system architecture to do with requirements?

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 )

Connecting to %s