Presentation is loading. Please wait.

Presentation is loading. Please wait.

G&W Chapter 25: Ending Software Specification Lecture 32

Similar presentations


Presentation on theme: "G&W Chapter 25: Ending Software Specification Lecture 32"— Presentation transcript:

1 G&W Chapter 25: Ending Software Specification Lecture 32
Prepared by Stephen M. Thebaut, Ph.D. University of Florida

2 Part V: Greatly Improving the Odds of Success
Ambiguity Metrics Technical Reviews Measuring Satisfaction Test Cases Studying Existing Products Making Agreements Ending

3 Themes Ending the requirements PHASE requires courage; It ends when you have enough agreement to risk moving into the design phase. Requirements WORK, however, never ends. It is unethical and unprofessional for requirements engineers to make self-serving design decisions, or to “bury” design issues for fear of later recriminations.

4 Ending the Requirements Phase Requires Courage…
…And it’s human nature to invent ways to reduce the courage needed, e.g.: Automatic design and development (when you think you might be finished, just press the button and see what comes out…) If trial products are cheap, then we can be quite casual about finishing requirements work.

5 Ending the Requirements Phase Requires Courage… (cont’d)
Hacking (development work with no explicit requirements work, so the problem of ending is eliminated) When we hack, we build something, try it out, modify it, and try it again. When we like what we have, we stop. (Note: this sounds a lot like evolutionary prototying…)

6 Requirements Work Never Ends…
Some attempt to combat their fear of changing assumptions by simply declaring: No changes to requirements will be allowed. G&W call this the “freeze fantasy”. A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment. – Lehman and Belady

7 Requirements Work Never Ends… (cont’d)
So, what is the last step in the requirements process? Agreeing to a Renegotiation Process

8 Remember the Alamo Highway Dept. Example
Highway engineers were making life-and-death decisions in a way that “covered their butts…” If I never thought about it, I’m not responsible for overlooking it in the design. And if it’s never written down, who could say they had thought of it?

9 Remember the Alamo Highway Dept. Example (cont’d)
Both sides of the barrier issues should have been documented and passed on to elected authorities for resolution. But what if the politicians came back with an impossible requirement? The highway curve must be redesigned so that there will be no fatalities in five years. (with very high probability)

10 There is more to say about Ending, but…
We must accept the risk of leaving some ideas imperfect and some revelations invisible, and stop. But don’t fear: I agree to discuss these ideas and any invisible revelations of interest…at least through the end of the course.

11 G&W Chapter 25: Ending Software Specification Lecture 32
Prepared by Stephen M. Thebaut, Ph.D. University of Florida


Download ppt "G&W Chapter 25: Ending Software Specification Lecture 32"

Similar presentations


Ads by Google