Just start over again (44)

Colleague Benjamin shared an article that triggered me. It’s in Dutch so let me briefly explain what it’s about for non-Dutch readers. A new system has been developed for publishing legal documents on public services and environmental plans. The new system turns out to be?non-workable: the system doesn’t offer the possibility for storing all necessary data. Also the new system isn’t backwards compatible: documents based on the current system can no longer be published and maintained within the new system. Reading through the article I envisioned failures throughout the whole requirements engineering process and specifically on sources for elicitation of requirements.

The IREB Foundation syllabus classifies the following types of sources for requirements: stakeholders, documents and systems. Stakeholders are considered to be the main source for requirements and include users, sponsors, developers, authorities and customers (among others, not limited to). Documents can be any kind documentation available inside and outside your organization. IREB gives examples like process documents, legal or regulatory documents and company-specific regulations. And lastly systems where IREB refers to existing and legacy systems. Especially when you are rebuilding a system the source types documents and systems can be very important. The system to be rebuild is a great source for eliciting requirements for the new system. But also documents that go with the system (like existing requirements, user and maintenance documentation, installation manuals etc.).

Looking at the article it’s unclear if stakeholders have been consulted in the elicitation phase (the article mentions that two important stakeholders worked quite past each other resulting in a system written in a language that can’t be used by one of the stakeholders!). When you consult stakeholders this doesn’t guarantee that you will be able to gather all requirements. This is illustrated within IREB by referring to the Kano-model. Even if stakeholders have been consulted there are requirements so obvious to them that they simply don’t mention these requirements during the elicitation phase. The so called subconscious requirements. Although stakeholders, according to IREB, are the main source for requirements, we should always look for other sources This brings me to the other types of sources: documents and systems.

The current system and the standards on which it is based with all its documentation is available. For example the article mentions the fact that the current system supported up to 50 information elements that could be part of a document. The new system only contained 15! So what did happen with the other 35 information elements? Where do you store that information while creating documents in the new system? And how do you publish documents with the information that’s already available in the current system? From the beginning it was clear that no data should be destroyed indicating the new system should be able to publish the information created with the current system! However the article reports that information architects didn’t look at the current system and the standards on which it is based, they seem to have failed to look at everyday reality and didn’t verify against daily practice.

The article concludes with explaining stakeholders have lost all faith in the new system. Repairing the new system seems impossible because of the foundation being wrong in the first place. This can only be solved by going back to the drawing board and begin from scratch. Would you like to prevent this from happening within your organization? Me and my colleagues from Improve can help you to improve your requirements process.

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)

41. Adapt requirements (and your process) to your development approach! (Erwin Pasmans, September 21, 2021)

42. ISTQB and IREB are joining forces (Piet de Roo, September 28, 2021)

43. New stakeholders (Benjamin Timmermans, October 5, 2021)