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.


Do we care enough about requirements?

My first post…

Hi I have been working with requirements for years now and am absolutely amazed about process many organisations apply when they write requirements. I have thought many things over the years and here are some things:

Why bother doing reviews on technical specifications when you don’t know the rationale behind the requirements?

Why write requirements if you know that the design organisation doesn´t care and almost have the design ready before the requirements are written?

Why put hours and hours behind a requirements management tool and a solid process for managing your requirements when you don’t put the same effort into the design of the requirements and specifications?

Why do organisations not realize that an error found in a faulty requirement only cost a fraction in cost compared to an error seen in the product?

I want to address these issues and many more in my blog an invite you to add topics you would like to discuss. Let’s make this the best requirements blog on the planet J

I will finish this first post with a story from the wonderful fairy-tale Alice in Wonderland. It is cute and just imagine if your organisation is like Alice? Do you know where you want to go with your Requirements Engineering work, or do you not care?

Hope to meet you on-line!

One day Alice came to a fork in the road and saw a Cheshire cat in a tree.

”Which road do I take?” she asked.

”Where d o yo u want to go?” was his response.

”I don’t know”, Alice answered.

”Then”, said the cat, ”it doesn’t matter.”

– Lewis Carroll