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