Requirements and design? (33)

Last week Piet de Roo discussed the how in requirements engineering. He mentioned 2 aspects of how: first one resulting in a constraint and the second one leading to quality requirements (non-functionals). There is a third aspect to the how: how are we going to realize the requirement in the actual product or system? Typically this is referred to as design during development processes.

In a previous article colleague Patrick Duisters referred to the Twin Peaks model (article in Dutch where he renamed the model to twin pines because the model looks like two pine trees intertwined). In complex environments, where there is a combination of hard- and software development taking place, I’ve come across what you could call a double V-model.

There are environments where a clear distinction is made between requirements engineering process, activities and artifacts alongside to the design perspective. In these types of environments waterfall, V-model and agile development approaches appear to be used in combination. Starting and ending the development approach waterfall or V-model style, in between agile where requirements, design, build and part of testing is executed in an iterative/incremental way.

Coming back to requirements and design, how do you decide what’s requirements and what’s design? According to IREB an important rule to follow with requirements is try to avoid providing solutions in a requirement. However at the same time this can be very inconvenient.

For example: as a requirements engineer I’m working for a company that builds and sells laptops. I’ve to specify requirements for a new model laptop (without providing a solution). I want to be able to connect a device to the laptop to be able to share or extend my screen. I could go into length to describe the minimum required pixel dimensions, refresh rate, color schemes and so on. Or I could specify: I want an HDMI and a display port on the laptop (alongside with 3 USB-B ports, a USB-C port, power inlet, and so on, and so on). I think most of us would agree specifying the HDMI port is an example of providing a solution. By doing so you will not get anything else on the laptop even when future state of technique perhaps has a different (and perhaps better) solution for connecting an external ‘display’ device.

IREB offers guidance in the process of requirements engineering. They don’t enforce you to do anything. We can be pragmatic about this. There will be situations where it can be beneficial to have a clear separation between requirements and design. Depending on the demands within the organization perhaps a combination of requirements and design is perfectly fine. For example have requirements specified by user stories with added examples to further specify and clarify the how. What do you think?

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)

32. How? (Piet de Roo, July 20, 2021)