architecture · NLP · requirements · Uncategorized

Fifty shades of requirements, part three – Architecture distortion

Hi again,

This time I want to talk about the “next” step in the requirements journey. I can right away say that I am a fan of agile and rapid development, but for the sake of this chat I like to describe a stepped approach. A newly formulated requirement should materialise on the solution side as one or many design elements. These elements form part of the architecture.

If you remember the blog here by Hillary Sillitto he described different views: System, Operational, Physical, Functional. The book he have written on architecting is brilliant and really to recommend. All of these views should capture different aspects of the design suggestion that eventually satisfy all the stated requirements. That’s all well, but what tend to happened in may cases?

We really now start to compare apples with pears (or should I say fruit salad?). Its really hard to compare written text with models. Are they correct, complete or are we missing something.


So, is this a big deal? Well if we make a recap from last post. I then argued that most errors (and I then mean errors not found with a spell checker) are brought to the architects and system designer I need to validate that their proposed solution is Ok, right? But If I can not really penetrate their ideas because they are using other techniques, tools and languages I might loose that ability. Do you agree?


The graph really show that the architects and designers are pretty good at doing their job and they find more errors due to the bad requirements than they produce and that’s a relief, but they will probably not find those errors that are caused by ambiguities, missing parts or plain wrong information. The architects produces and architecture that is supposed to cover all aspects that has been stated in the requirements, but they should not do anything if they don’t find a requirement justifying the design element or function.

One can argue that techniques like Model Based Systems Engineering (MBSE) are solving a great number of complexity issues and you can do so much magic when you are able to look at those views to see the complete picture, but you can not really validate it with people that don’t “read” SySML. Those people are all the stakeholders, customers, users that you so desperately need to communicate with and they don’t speak your language as an architect. Ok, again its now possible to add a requirement view in the modelling tools, but then you are just adding a notepad functionality and you miss all of issues of having correct semantics and syntax. You are basically back where you started (you have just moved them to another domain and probably tool).

Major problems in the transformation from in this case written requirements in one language (let’s say English) to an architecting language like UML or SYSML is the inability to validate Correctness, Completeness and Consistency. A rather academic picture and text I have stolen from my friend and colleague Prof. Juan llorens (sorry!) is this:


Bearing in mind that the goal of requirements is to specify a product, service or system, then we have two complementary points of view to define good or bad requirements. From the point of view of the sender, the final quality of requirements is validability, i.e., the sender must be able to confirm that the system architecture effectively expresses the system solution that answers his or her needs. This property can be further unfolded, in a second level, into three other properties: completeness, consistency and understandability.

From the point of view of the receiver, instead, the two essential qualities are: verifiability, i.e. it is possible to check that the developed system architecture meets the specified system requirements; and modifiability, i.e. it is possible to modify the architecture to enable change. Verifiability depends on the same three second-order properties already mentioned (completeness, consistency and understandability), as well as on three other properties: unambiguity, traceability and abstraction; modifiability depends also closely on these three last properties.

Unambiguity and understandability are interrelated (according to some, they would be even the same property), since, if a requirement is ambiguous, then it cannot be properly understood. Note also that abstraction and unambiguity are not opposing concepts: a requirement must have a single interpretation at the abstract level of specification (unambiguity) and at the same time must avoid technical details about the implementation (abstraction).

Other things worth mentioning is also that organisations seldom have one tool from one tool vendor, they have probably multiple tools spread and used differently in different parts of the organisation and to that we can ad a layer of self-made hacks, spread sheets and databases.

At one point I will write a future blog post on using natural language processing, requirement patterns and techniques to decode the language so that one can create requirements out of models (or vice versa), but for now I will say good night, auf wiedersehen and hope you read next blog on the test phase.

I have called it “the test catastrophe, but lest push on for that delivery”.

architecture · NLP · requirements · Uncategorized

Agile doesn´t work!?

By starting with the statement “Agile doesn´t work” you really ask for trouble these days. I was attending a conference earlier this week and I meet Agile coaches, Agile Managers, Agile Testers, Agile Requirement Engineers and Agile Evangelists in general. The conference itself was very good and I got the possibility to talk about the requirements role for a successful project. Unfortunately, I needed to leave early so perhaps you might call me an Agile planner?

No, but on the metro back to the office (you know my Agile Schedule) a LinkedIn post by Oleg Vishnepolsky, CTO at DailyMail in UK, caught my attention. It started “Agile does NOT work!”.


He started; “Try telling someone that you are not agile. You might be arrested on the spot. The issue is that the word agile in the eyes of everyone is similar to the word good. Try telling others that you are not good, and they will call for a psychiatrist.”

I continued to read the post with great joy. I think he is spot on!!

Why Agile isn´t a silver bullet

Agile can be defined as “Agile (software) development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams” (source Wikipedia).



First of all, don’t get we wrong. I don´t like the approach with “analysis paralysis” and so heavy front loading that you never get through the first base of requirements elicitation and definition. Many organizations have historically lacked the ability to say “this is good enough” and moved further in the development chain. If you stop to long the inertia of badly performed Systems Engineering will force the project to continue and start to develop stuff regardless. They have deadlines and a customer to satisfy, AND doing Agile projects makes it easier to skip the boring work of documenting both requirements and design. The team can go right ahead and do the fun stuff..

But is Agile as an opposite the salvation of any badly performing organization with schedule overruns, lost margins, port system quality and unhappy stakeholders?

I would argue not! You have the same people coming to work, but now let’s do the mistakes in an Agile manner instead.

Well, of cause, Agile basic principles are nice and I do like them:

  • You have customer focus (instead of technology focus)
  • You divide the work in suitable chunks, and;
  • You group in teams instead of stove pipes so that you get much better cross pollination of views and ideas. That’s great!

But it is still humans that needs to understand the problem they are there to solve. Perhaps Agile is a way of getting it better, but not getting it right? Could an old Waterfall organization that goes Agile like this approach because it reveals the problems earlier than before? Are they really looking into the root cause of the problems they are facing (which haven’t gone away just because you went Agile).

The common-sense methodology

Mr Vishnepolsky introduces the common-sense methodology and I like that thinking very much. Instead of digging trenches and throwing dirt on anyone not from the right belief, you might like to make a short retrospect and look at yourself before you continue this argument.

I would like to add my small contribution: For god sake, look at the scope and early requirement definition phase and do it with FOCUS and a sence of INFORMATION QUALITY!

Making it right from start so that people understand what you mean

Ok, I might add that you can develop this type of knowledge using an arbitrary methodology, but just for the sake of it say that you write some business or stakeholder requirements to make sure that you understand the problem you are there to solve. After you have agreed with the stakeholders the task at hand (to a reasonable level of detail) you might develop technical requirements using natural language techniques (writing requirements) and/or doing some system modelling to get the system boundary and interfaces in place. You might have read the architecting blog series here by Hillary Sillitto?!

But who do you have in mind when you do this work? You are not doing this because it’s fun or because someone asked you to, you do it to COMMUNICATE with others. The stakeholders need to understand your solution to his/her need AND the next person receiving your information (developers, testers, integrators, etc.) also need to understand what you are proposingIT_DEPENDSSo, please start to do your requirements with some level of curiosity from the team working with them. You really need to understand their role here as drivers of knowledge from one part to the next. They first of all need to be correct and together with their other requirement siblings at the same abstraction level, they need to be complete (to the degree to level risk and avoid costly errors) and also not in conflict with each other so that one says “right” and another “left”.

But primarily, human write requirements for other humans. Perhaps using a second language and communicating through barriers like: culture, development contracts, technology domains and/or business hierarchies.

That’s my contribution to the common-sense discussion. Over and out!

Read the post by Mr Vishnepolsky here: