How? (32)

About half a year ago I wrote a blog on the word "why". Actually it was in Dutch and it was titled "Waarom, waarom, waarom, …" ("Why, why, why, …"). I then stated that although repeatedly asking "Why?" can be very annoying “Why?” often is a good question to ask as the answer may help you discover the rationale for a requirement. In the current blog I want to discuss the word "How".?

To make a distinction between functional requirements and quality requirements it is often said that functional requirements describe what a system should do and quality requirements describe how it should do it. I think this is confusing to say the least. The confusion is illustrated by an example given in the most recent version of the Handbook for the CPRE Certified Professional for Requirements Engineering Foundation Level:

“The customer entry form shall contain fields for the customer’s name and first name, taking up to 32 characters per field, displaying at least 24 characters, left-bound, with a 12 pt. sanserif font."

This sentence describes a completely functional requirement. The first part describes what the entry form of the system shall have: a field for both the name and the surname. The rest is interpreted as the how. In this example the how does not describe any quality requirements but merely implementation details (this many characters, this font type, this font size). So this is not the how we talk about when looking for quality requirements. Actually in English the word can have two meanings. According to the dictionary it can mean:

1.?????in what way or manner; by what means

which is the way it is used in the above example, or it can mean:

2.?????to what extent, degree

The latter meaning is referring to something one can measure and one can demand an upper or lower limit for.

Something seems to be missing though and that is an indication of the quality aspect you are referring to. Without that the question "How?" is not a suitable question for elicitation, or is it? Well, you can get useful information when you ask how. If a painting must be hung, one can ask how the painting must be hung. The answer will probably be something like "Using a nail". This narrows down the solution space, so it is valuable information, but not quality information. It is merely a constraint.

In order to find out what the quality requirements are we must help the stakeholder being interviewed by specifically asking for a certain aspect of quality. How reliable must the system be? How fast should the transactions be processed? How easy should it be to update the firmware? And when you ask these questions you should be aware of two things.

Firstly there are a lot of quality aspects you can ask for. If you don't address them explicitly the stakeholder might not mention them at all. To make sure you don't forget anything you best use a checklist, e.g. based on the ISO 25010 standard. And secondly, not all quality aspects can easily be measured. If the requirement for a car is that it can accelerate quickly, one simple measurement can confirm that it meets the demand. If a new software product should be learnable for elderly people you probably have to define acceptance criteria based on an experiment with a representative sample of elderly people that try and learn to operate the product.

To get a complete picture of the requirements the requirements engineer should ask three questions:

1.?????What is the problem to be solved? (the functional requirement)

2.?????How do you want it to be solved? (constraints)

3.?????How <adjective> must the solution be?

So in fact it is more than three questions, it is 2 + the number of relevant adjectives you can come up with. Adding a tablespoon of when, a pinch of where, and five why’s gives you the ingredients for a stakeholder interview.

Make sure to also put in a lot of practice, because just knowing the ingredients doesn’t guarantee a high quality meal.

This article is an article?in the series about the versatile profession of?requirements?engineering. Every week a?colleague?of?Improve Quality Services?will share with the reader an aspect of?requirements?engineer?from daily experience.?Every article begins with a picture of a bridge. The bridge visualizes connecting two sides. In requirements engineering connecting different stakeholders?assisting the stakeholders?in collaboration and communication about requirements.?

Articles published till date (mostly in Dutch):?

1.?Requirements?(Piet de Roo, December 1, 2020)

2.?Shared Understanding?(Kaspar van Dam, December 8, 2020)

3.?Context en requirements structuur?(Patrick Duisters, December 15, 2020)

4.?Van Twin Peaks naar Twin Pines?(Patrick Duisters, December 22, 2020)

5.?Modellen om te bouwen?(Erwin Pasmans, January 5, 2021)

6.?Minimaal Modelleren?(Piet de Roo, January 12 2021)

7.?Begrip en Vertrouwen?(Benjamin Timmermans, January 19, 2021)

8.?En wat als de specialisten het niet met elkaar eens zijn??(Benjamin Timmermans, January 26, 2021)

9.?Waar zijn we nou helemaal mee bezig?!?(Erwin Pasmans, February 2, 2021)

10.?Soft skills? Keiharde wetenschap!?(Kaspar van Dam, February 9, 2021)

11.?… en nu enkele feiten: Requirement Attributen?(Patrick Duisters, February 16, 2021)

12.?Waarom, waarom, waarom, ...?(Piet de Roo, February 23, 2021)

13.?Een leven lang zorgen?(Erwin Pasmans, March 2, 2021)

14.?Casus: Requirements management bij een distributiecentrum in aanbouw?(Eduard Hartog, March 11, 2021)

15.?Iteratief versus Incrementeel?(Kaspar van Dam, March 16, 2021)

16.?Requirements of-the-shelf: geen maatwerk, geen requirements??(Erwin Pasmans, March 23, 2021)

17.?Creatief door constraints?(Piet de Roo, March 30, 2021)

18.?3 Amigo’s?(Patrick Duisters, April 13, 2021)

19.?4 Amigos (of meer?)?(Patrick Duisters, April 20, 2021)

20.?Requirements, de CoronaCheck-app en Fred Flintstone?(Benjamin Timmermans, April 28, 2021)

21.?Meer kapiteins op 1 schip (of staan de beste stuurlui aan wal)??(Erwin Pasmans, May 4, 2021)

22.?Hoe SMART is SMART??(Benjamin Timmermans, May 11, 2021)

23.?Jip en Janneke?(Piet de Roo, May 18, 2021)

24.?Laten we het simpel houden?(Patrick Duisters, May 25, 2021)

25.?Dilemma's??(Erwin Pasmans, June 1, 2021)

26.?Living?Documentation?Event 2021?(?(Kaspar van Dam, June 8, 2021)

27.?Non-functional Requirements?(Patrick Duisters, June 15, 2021)

28.?The Big Shift?(Kaspar van Dam, June 22, 2021)

29.?Why do we have these problems over and over again???(Erwin Pasmans, June 29, 2021)

30.?Non-functionals, who cares??(Benjamin Timmermans, July 6, 2021)

31. Usability and UX, a revelation I had (Benjamin Timmermans, July 13, 2021)