登录查看更多内容

Requirements: Do we really need them? (38)

Kaspar van Dam

Game changer and Consultant BDD/Agile Requirements/Test @ ICT Improve

发布日期: 2021年8月31日

As you may have noticed there’s a number behind the articles I post on Requirements Engineering. This one has the number 38. It means this is the 38th?article we wrote on the topic of Requirements Engineering and how it builds bridges (people with a keen eye may have also recognised all 38 articles show a picture of a bridge). When I say we I mean myself and?a number of?my colleagues at ImproveQS who are pretty?much?fanatics about Requirements Engineering… Knowing?that,?the topic of this article may surprise you… After 37 articles I pose this question: Do we?actually need?those requirements???

Unfortunately?there isn’t a simple yes/no-answer to that… It’s?all?dependent on context, on the topic, the project, the process but most importantly on the people involved. Do they need requirements to do their work properly? Do they need to know exactly what to design, build, test? Or can we get away with just giving them some vague idea and good luck with it??

When we started with this series of articles on December 1st?2020 we at Improve asked ourselves the same question. We were planning to write a series of articles on Requirements Engineering?and wondered ourselves what would be the requirements for this series. We decided to not make any real requirements for it and just start?… Only thing we discussed is that we wanted to always try and post a new article on Tuesdays, that we wanted them to have a picture of a bridge and that was it! (So we did have two requirements).?

That means we had no requirements for what should exactly be in it, we also had no requirements concerning the language of the articles, no requirements how to make it visible the articles were part of a series, no requirements on how there would be a common topic in the articles, a certain leitmotif (or ‘Rode?Draad’ in Dutch), no requirements on who would write something when. Nothing. We just decided to let it evolve on it’s own. And it did!??

Without all those explicit requirements we are now at number 38 of the series.?With the exception of?one?article?they were all published on?Tuesdays?and they all showed a picture of a bridge. But besides that everything evolved organically. In time we decided to add a text below each article, links were added to all previous articles, we?added a number to the title to show which ‘episode’ in the series the article is and at some?point?we decided to switch from Dutch to English. The one thing that almost went?wrong was the posting of an article every Tuesday because this week we were at a loss?….?None of us had any?time or?inspiration, some of us are still on vacation. And that means it’s now Monday afternoon and I’m writing this article?… Because inspiration comes in the strangest?of places: the lack of inspiration for a new article became the inspiration for this one!?

For a moment I thought the lack of requirements was now finally going to break us up after 37 weeks of great articles?….?But it obviously didn’t because it’s Tuesday again and here you are reading episode 38 in the series!?

So… It is very well possible to have?a pretty ambitious?project (writing blogs weekly for an entire?year??Honestly we don’t know for how long we’ll be doing this: there’s no requirement for that!)?and have it be successful without a lot of well-defined requirements.?

?Now, does this also apply for IT projects? I guess it does. But as mentioned at the beginning of this article it’s very dependent on context, topic, project, process and most importantly: people.??

Can people handle?that much?‘freedom’? Will they take responsibility to give it all their best all the time? And is there enough room for continuous communication between people making things happen and the stakeholders who want something to happen? If so: no?(detailed)?requirements?needed. However: in reality?Continuous?Communication between all stakeholders isn’t always possible. And truth be said: most of the times it simply isn’t an option. So that means things need to be written down. And when you start with that you’d better write them down in a way that’s clear to everyone involved, unambiguous, to the point and clearly describing what the problem is that needs to be solved. In other words: in the real world we usually do need those requirements!?

And on behalf of me and my colleagues: see you next Tuesday (?I am already wondering who will be writing part 39 and what it’ll be about…).?

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)?