Requirements Determination is Unstoppable: An Experience Report - - PowerPoint PPT Presentation

▶
requirements determination is unstoppable an experience
SMART_READER_LITE
LIVE PREVIEW

Requirements Determination is Unstoppable: An Experience Report - - PowerPoint PPT Presentation

Feb 19, 2024 247 likes •858 views

Requirements Determination is Unstoppable: An Experience Report Daniel M. Berry, CS; Krzysztof Czarnecki, Micha Antkiewicz, Mohamed AbdElRazik, ECE; University of Waterloo 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M.

slide-1
SLIDE 1

Requirements Determination is Unstoppable: An Experience Report

Daniel M. Berry, CS; Krzysztof Czarnecki, Michał Antkiewicz, Mohamed AbdElRazik, ECE; University of Waterloo

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 1
slide-2
SLIDE 2

Some Terminology

Requirements analysis (RA) is known also as “requirements engineering (RE)”. Requirements specification (RS) is what RE yields. Requirements determination (RD) may or may not be done as part of RE.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 2
slide-3
SLIDE 3

Requirements Determination

RD is the making of some requirements relevant decision … perhaps as small as deciding one word in a RS. RD may or may not be part of any conscious RE process.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 3
slide-4
SLIDE 4

Consulting at Company X

X has a well-managed IT department. X’s IT department has produced award- winning applications. Nevertheless an X VP asked us to look at their RE process for problems.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 4
slide-5
SLIDE 5

How We Did the Consulting

Semi-structured interviews with 18 people: g 5 focus groups g 23 hours of recordings capturing about 40 people’s remarks g logged hundreds of quotations

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 5
slide-6
SLIDE 6

Clustering the Quotations

While clustering the quotations, we noticed that they told a story, … a story that some of us had seen before.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 6
slide-7
SLIDE 7

A Model of the Lifecycle

From the story, we came up with a model of X’s software lifecycle using long-understood ideas from the RE field. The model explains about 95% of what we heard.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 7
slide-8
SLIDE 8

Outline of the Rest of Talk

g Paraphrases of some quotations g The model, in three parts, Model I, Model II, and Model III g Conclusions and implications of the model g What happened at presentation of the model at X

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 8
slide-9
SLIDE 9

Paraphrases of some quotations

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 9
slide-10
SLIDE 10

Not enough time for RE.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 10
slide-11
SLIDE 11

RE is timeboxed.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 11
slide-12
SLIDE 12

Coding starts too early.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 12
slide-13
SLIDE 13

Coding is done to early requirements.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 13
slide-14
SLIDE 14

Results in many project change notices (PCNs).

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 14
slide-15
SLIDE 15

Stealth changes with no PCN to avoid reproach a PCN earns.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 15
slide-16
SLIDE 16

Testing effort estimated based on very early requirements.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 16
slide-17
SLIDE 17

It seems that …

RE is being stopped before it has run its course.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 17
slide-18
SLIDE 18

Reality

Michael Jackson [1995] once said: “Requirements engineering is where the informal meets the formal.” g Raw ideas: informal g Code: formal → Model I

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 18
slide-19
SLIDE 19

Informal Meets Formal (Model I)

Client Ideas Code Test Cases

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 19
slide-20
SLIDE 20

Two Extremes:

g Upfront RE, in which as much time as necessary is spent to determine requirements before proceeding with design and implementation. g RD during coding, in which the programmers and testers determine all requirements as they write the code and test cases.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 20
slide-21
SLIDE 21

Informal Meets Formal (Model I), Cont’d

RD During Coding Upfront RE

Client Ideas Code Test Cases

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 21
slide-22
SLIDE 22

In Most Projects…

the meeting point is somewhere in the middle.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 22
slide-23
SLIDE 23

Meeting Point is Unavoidable

There is no way to go from ideas to code without determining requirements for the code from the ideas. That is, no programmer can write code without knowing what the code is to do, even if he or she has to decide what the code is to do on the spot.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 23
slide-24
SLIDE 24

When upfront RE cut short, …

the RS is incomplete.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 24
slide-25
SLIDE 25

When programmers receive an incomplete RS, …

they cannot continue until they decide what the missing requirements are.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 25
slide-26
SLIDE 26

How programmers should decide missing requirements?

They should ask the client.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 26
slide-27
SLIDE 27

When programmers ask the client, …

delay

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 27
slide-28
SLIDE 28

Sadly, …

Often, the programmer does not ask the client: g cannot find client, or g has no access to client

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 28
slide-29
SLIDE 29

So, …

the programmer invents requirements on the spot. ( It’s called “creativity” or “initiative”! )

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 29
slide-30
SLIDE 30

When programmer invents, …

It’s not good, because: g Programmers are not trained in RE. g Programmers have interests that are different from the client’s, to simply their

  • wn coding.

g Each programmer needing a missing requirement is working independently.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 30
slide-31
SLIDE 31

Throw in Testers

Add to all this that the testers are trying to write test cases for incomplete requirements. Ergo, even more independent invention of requirements.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 31
slide-32
SLIDE 32

Programmer- and Tester- Determined Requirements

They are bad…. and They are expensive. → Model II

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 32
slide-33
SLIDE 33

Why Expensive? (Model II)

200 150 100 50 Reqs Specs Plan Design Code Integ Maint 1 2 3 4 10 30

Relative cost to fix fault Phase in which fault is detected and fixed

200

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 33
slide-34
SLIDE 34

Perceptions

How do people perceive any new requirements determined after delivery of the RS?

Creep!

even though the new requirements may be what was missing because of terminated RE.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 34
slide-35
SLIDE 35

Logical Conclusion for Models I & II

RD always continues until it answers all questions any programmer has about writing the code and any tester has about writing test cases. g There is no escaping this reality. g It’s like death and taxes!

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 35
slide-36
SLIDE 36

Logical Conclusion for Models I & II, Cont’d

The client must be accessible for the entire duration of RE. We are talking about the actual duration of RE, not the official duration, … especially if the actual duration of RE is the full lifecycle.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 36
slide-37
SLIDE 37

Logical Conclusion for Models I & II, Cont’d

The client must be accessible for the entire duration of …

RD.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 37
slide-38
SLIDE 38

But, But, But … If we don’t stop RE, it will go on forever!

Like a mother’s work, RE is never done!

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 38
slide-39
SLIDE 39

Yes and No

Yes: There are always new requirements for software that is being used [Lehman], … and iterative methods are for dealing with those kinds of new requirements.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 39
slide-40
SLIDE 40

Yes and No, Cont’d

No: Once a scope is picked — and you cannot complete the code without pinning down some scope — there are no new requirements, only as yet undiscovered requirements.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 40
slide-41
SLIDE 41

How to Know if RE is Done-1:

RE for a scope is done when the RS is complete enough that every … programmer can program the required code … without having to ask anyone to clarify a requirement and without having to invent any requirements on the spot. Every good programmer knows such an RS instinctively.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 41
slide-42
SLIDE 42

How to Know if RE is Done-2:

RE for a scope is done when the RS is complete enough that every … tester can write the required test cases … without having to ask anyone to clarify a requirement and without having to invent any requirements on the spot. Every good tester knows such an RS instinctively.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 42
slide-43
SLIDE 43

Another Conclusion for Models I & II

At least one programmer and one tester should be part of the RS writing team … in order to help the team determine when to continue and when to stop.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 43
slide-44
SLIDE 44

BEGIN SKIP FOR CONFERENCE:

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 44
slide-45
SLIDE 45

Model I Applies to Iterative and Agile Lifecycles

The full line is repeated for each iteration. Each iteration serves as part of the RE for the next iteration.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 45
slide-46
SLIDE 46

Model I Applies to Iterative and Agile Lifecycles, Cont’d

In an agile lifecycle, g the scope is smaller and g the client is available all the time. So it’s OK that the programmer is doing RD as he or she writes code.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 46
slide-47
SLIDE 47

END SKIP FOR CONFERENCE:

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 47
slide-48
SLIDE 48

Not In Paper

There was no room for the following in the paper. However, it is the third model. If time permits, I will cover it! If not, I will only mention it and move to the conclusions.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 48
slide-49
SLIDE 49

Problem of the Lack of Benefit

  • f a Document to its Producer

(PotLoBoaDtiP)

This problem plagues all the documents that people just hate to write or to keep up to date. PotLoBoaDtiP was first identified by Paul Arkley & Steve Riddle as the traceability benefit problem. But, the problem exists for more than creating and maintaining traces.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 49
slide-50
SLIDE 50

PotLoBoaDtiP (Model III)

PotLoBoaDtiP occurs whenever those who have the knowledge to produce a document are not the ones who benefit from the document, and… those who benefit from the document, its consumers, do not have the knowledge to easily and quickly produce the document when they need it.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 50
slide-51
SLIDE 51

PotLoBoaDtiP

At best, for doing the document, the producer suffers drudgery; at worst, the producer suffers rebuke. At best, for not having the document, the beneficiary suffers drudgery; at worst, the beneficiary suffers an impossible task.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 51
slide-52
SLIDE 52

Consequences of PotLoBoaDtiP

rebuke drudgery impossible task drudgery worst best

Beneficiary Producer

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 52
slide-53
SLIDE 53

Example 1 of PotLoBoaDtiP

requirements and code traces between

drudgery drudgery best

Beneficiary Producer

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 53
slide-54
SLIDE 54

Example 2 of PotLoBoaDtiP

PCN

rebuke impossible task worst

Beneficiary Producer

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 54
slide-55
SLIDE 55

Technology Does Not Solve PotLoBoaDtiP

There are lots of tools out there for tracing. But, just as there is no incentive to produce the trace, there is no incentive to use the tools. PotLoBoaDtiP must be addressed as an incentive problem.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 55
slide-56
SLIDE 56

Conclusions

g RD continues until all programmers’ and testers’ questions are answered. g Client must be accessible throughout actual RE. g Programmers and testers should help determine when RE is done. g PotLoBoaDtiP should be addressed via incentives.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 56
slide-57
SLIDE 57

Presentation to X’s VPs

X’s VPs expected boring presentation about quotations and their frequencies and limited

  • ur presentation to 15 minutes.

We surprised them by presenting only a summary of the quotations and then focused

  • n the model and its conclusions.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 57
slide-58
SLIDE 58

We believe that …

focusing on the model was the right thing to do… because of the lively 1⁄

2-hour discussion that

ensued. One VP said that we hit the nail on the head!

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 58
slide-59
SLIDE 59

Now Go Read Our Paper!

But please be polite to the other authors of this session, and stay until the end of this session.

 2010 D.M. Berry, K. Czarnecki, M. Antkiewicz, & M. AbdElRazik Requirements Engineering RD is Unstoppable

  • Pg. 59