Adapt requirements (and your process) to your development approach! (41)

In most, perhaps even all, articles we’ve written in this series, development approaches are mentioned. Typically waterfall, V-model or iterative/incremental/agile. In this article I want to share some of my thoughts about requirements in relation to development approaches.

When organizations first started moving towards an agile way of development, the agile manifesto was embraced. The manifesto described 4, or 8 depending on how you look at it, values on how the new approach could be towards software development. One of the values, “working software over comprehensive documentation”, however frequently appears to be explained in a way that probably was never intended by the authors. The authors stated: “That is, while there is value in the items on the right, we value the items on the left more”. Organizations appear to adapt this value as: working software and no documentation. Focusing on value on the left part resulting in also not documenting requirements. This approach obviously had all kinds of negative effects on developed software and systems. Although stakeholders received working software at the end of an iteration, it wasn’t always what they were expecting. Also handing over to maintenance teams led to challenges. The maintenance team had no clue what was handed over to them. As a result if incidents occurred or changes where needed the maintenance team was not able to effectively and efficiently solve these issues.

Nowadays there seems to be change in mindset. There is a change to be witnessed in the way of working in organizations and projects and an increasing number of people taking a requirements training over the last years. Gradually organizations are reconsidering the “no documentation approach”. The contents of the requirements will not be that different. There will however be a difference in the way the requirements evolve, who participates in that process and the structure and hierarchy of the requirements.

Within waterfall or V-model typically a more sequential approach will be used. Resulting in a set of requirement documents perhaps even following an international standard like ISO/IEC/IEEE 29148 describing requirements at stakeholder level (management and operational), system level, sub-system level and software level. On every level, more details are added. The documents are created by requirement engineers acquiring the needed information during the elicitation phase from all stakeholders. Once happy with the gathered requirements (validated by the stakeholders), the system will be built, tested and delivered. In order to be able to deal with changes throughout the project, change management processes where needed and implemented.

Working in an agile way there will also be a need for processes. However these processes will be less sequential. If there is a need epics will be documented. These epics will remain epics until, based on priority, a decision is made to further decompose them into features. For both epics and feature work is primarily done by people with a requirements engineering role together with stakeholders. After that refinement can start within the teams resulting in user stories and examples (the living documentation part also frequently mentioned in the articles written). Still requirements engineers and stakeholders shall be involved working together with the team. Agile development approaches will also have a structure and a hierarchy: epic, feature, user story and examples. Changes and re-prioritization can happen at any time resulting in kind of like just in time (and just enough and just good enough) delivery.

In the end the result should more or less be the same: a documented system. It doesn’t matter what development approach you are using. Adapt your requirements process and the requirements to that approach! This is also described in chapter 5 of the most recent version of the IREB CPRE Foundation level syllabus; Process and Working Structure. You can follow this training at Improve Quality Services.

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 engineers 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 (articles 1 till 28 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)

33. Requirements and design? (Erwin Pasmans, July 27, 2021)

34. Tom's people skills to deal with the customers (Piet de Roo, August 3, 2021)

35. Requirements creep: the ideal pocketknife with 3000 functions (Benjamin Timmermans, August 10, 2021)

36. Requirements creep: good or bad? (Benjamin Timmermans, August 17, 2021)

37. End with the begin in mind (Piet de Roo, August 24, 2021)

38. Requirements: Do we really need them? (Kaspar van Dam, August 31, 2021)

39. Begin with the End in Mind (Patrick Duisters, September 7, 2021)

40. Solving the right problem (Piet de Roo, September 14, 2021)