Begin with the End in Mind (39)

In the past, articles from both Piet de Roo and @Kaspar van Dam touched my area of work being requirements engineering, testing and process improvement, often in regulated environments like medical and automotive. Raising the question if I agree (or not). While discussing future articles @Piet used my (future) title… ??.

What are the hooks? Well, if we need requirements or not, and ‘End with the begin in mind’.

Let me start with my simple ‘opinion’ to the question: Do we need requirements??

Well, “It Depends”, as my colleague Benjamin Timmermans often says.

As mentioned above, I’m frequently working in regulated environments and there the answer is simple: YES.? But of course I do realize that there might be situations where there is less need for requirements.?

Begin with the End in Mind (1)

But hey, that wasn’t the title that Piet used! In his post ‘End with the begin in mind’ he explained that why he shuffled Stephen R. Covey's words, and that finally the product should solve the user’s problem. This leaves me Covey’s words in the correct order, although it is not related to this second ‘habit’ of highly effective people. It is more related to how systems are developed, and what should be there at the end. I’ll elaborate on that in this article. And then you’ll also understand why I am convinced that requirements are needed in such (regulated) environments.

Requirements not at start

Together with Johan van Berkel in 2019 I presented our (and my) experiences and views on how requirements evolve in projects and how you best can deal with that in regulated environments.

Our experience was and is that for complex devices with hyper new technology in the early phases of the project there will be ‘initial’ requirements. Wise through harm and shame I’m convinced that these initial requirements seldomly hold until they become final product requirements. They will change and as such and better can be characterized as ‘expected behavior’ like expected performance, accuracy etc....?And that basically is the basis for my title:

Begin with the end in mind (2)

I have seen too many projects that start with the ‘expected behavior’ as if these preliminary requirements were ‘final’ requirements. Meaning: stable, and basis for testing and ‘formal verification’. From efficiency point of view: project management sees early test result as precious ‘evidence’ becaus evidence is an important prerequisite in getting market approval. No evidence of the ‘formal verification’, proving that your product conforms to the requirements means no market approval, meaning no sales, meaning no money.?

As stated, our experience is that these initial requirements seldomly hold, with as a result that this early evidence is no longer valid for the final requirement. Combined with the required maintenance of this evidence during development, these preliminary results become substantial waste.

My advice to management is that these initial requirements should not be considered as ‘requirements’ and the early evidence is ‘no evidence’.

It is better to expect and accept that there will always be changes. It is better to work towards that end point. Begin with initial requirements and make sure that the requirements ARE clearly written down at the end, and only then collect the formal evidence.?

Another benefit is that it is easier to write down what the system really does than what it should do. The time towards the endpoint can better be used for testing. Focus on what the system can do, also in all kinds of exceptional situations and corner cases. This gained experience can be used to develop the formal verification tests. Again it is better to work towards that end point. Evidence is immediate evidence without the overhead.

Doing so, the formal verification tests become 'just' a confirmation of the requirements and it also produces less annoying surprises like ‘defects’ that must formally be managed.?

Spot on the horizon

So, at the end there is need to have requirements (and here is the motivation to my earlier opinion) in a regulated environment (= context). How would you otherwise state (or in jargon: claim) what your product does and how you can prove that your product complies?

But from a management point of view: you cannot postpone the requirements engineering activities until the end and then just simply write down what the system does. No. It definitely requires a good process, good skills, and good management. Don’t forget the good cooperation with the testing team… (hey…! ??). On the other hand: as project management you might need to let loose that a requirement, once somehow recorded, is already a valuable part of the deliverable.??…it will be subject to change…

You must begin with the end mind (have I already mentioned that??): know that at the end there?must be (final) requirements that are managed and can be verified. But don’t start to treat the requirements too early as formal and ‘carved in stone’. It will bring a lot of change management, documents maintenance and overhead.

And the spot on the horizon? That is a synonym for the end in your mind, to prevent further repeating of ‘Begin with the end in mind’.

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

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