Requirements creep: good or bad? (36)

Last week I wrote a more lighthearted story about requirements creep which resulted in a pocketknife with 3000 functions. I just wrote about the result.

In this blog I want to elaborate a bit more seriously on the reasons for requirements creep. Why does this happen? How can we deal with this? And is requirements creep good or bad?

Good or bad?

Starting with the last question: is requirements creep good or bad? I do not know whether it is personal, but, for me, requirements creep has a somewhat negative connotation. It is something that you want to avoid at first as it results often in more work, more time, more money and it might result in a product which might be as ridiculous as the pocketknife with 3000 functions.

But trying to answer the good or bad question I have to look at the reasons for requirements creep. Why do new requirements enter the specification after the requirements are considered to be complete? And I see that there are a lot of reasons for this. To name a few (definitely not a complete list!):

????????i.???????????Jumping to solutions. Going too fast to a solution before you know what the actual problem is. If you go too fast, you will learn during the development process that you are doing the wrong things. Or in the worst case, you will learn this after the development process. Thus ending up with an unhappy customer.

??????ii.???????????Not knowing the stakeholders. How can you do a proper elicitation of the requirements if you don’t know the stakeholders? Or if you think you know the stakeholders, but you just learn later on, that the stakeholders list was not correct/complete? Or they are not available? And of course, it will also not help if even the wrong stakeholders are involved…

????iii.???????????How can you know whether the requirements are complete in case you are making something completely new? An invention? An innovation? When you don’t know the customer and actual use (yet)?

????iv.???????????Just not enough time for the elicitation of requirements. Pretty obvious for me. If you don’t take the time, you later on will learn. And there are several reasons for not taking/having/getting enough time: ignorance, pushing customers, unrealistic deadlines/estimates/timeboxes, pushing project managers to name a few…

??????v.???????????Not taking requirements engineering seriously. I believe requirements engineering is a profession. You need to be educated, trained, and experienced to do a proper job. If you underestimate this, the requirements will creep for sure.

Looking at this list, you might come to the conclusion that requirements creep is a bad thing. But I believe it doesn’t have to be a bad thing. It will be a bad thing when requirements creep comes as a surprise. You should take requirements creep into account upfront. You can deal, avoid, or at least minimize requirements creep:

????????i.???????????Make sure you work on the right level. And don’t mix these levels. Are you dealing with the problem of the customer (the question)? Or with the answer? Or with the solution? We already addressed this in several earlier blogs in this series.

ii./iii.??You don’t know what you don’t know. Anticipate. So create feedback loops. Do not work alone. Use your colleagues. Make sure your work will be reviewed regularly.

????iv.???????????I understand project pressure. It is your job to make it clear to other stakeholders what happens when, due to this pressure, you can’t do your job properly. Talk about the consequences, for both project (timing, budget) and (unhappy) customer.

??????v.???????????Make sure you have good professionals in your team. So not only good developers, testers but also requirements engineers. And with good, I mean trained and experienced??.

As you might have noticed, several mentioned problems will emerge differently depending on your approach. Whether you will have a more traditional (V-model) approach where you try to avoid requirements creep as much as possible (and as early as possible) or a more agile approach where you know and expect (and even want) the requirements to creep. ?

So, is requirements creep good or bad? As often, the answer is ‘it depends’. But as stated earlier, it will definitely be bad, when it comes as a surprise!

?

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 (the first articles are 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)