The Requirements Process for Software Systems

1. The Requirements Process for Software Systems Requirements Elicitation and Requirements Generation

2. Putting It Together • Principles • Rigor and Formality • Separation of Concerns • Modularity • Abstraction • Anticipation of Change • Generality • Incrementality • Notion of Process

3. “Standard” Software Creation Process Requirements Documents Gather Requirements Domain language Design Documents Generate Design Models, technical language Implementation Test Write Code

4. What Really Happens Requirements Documents Gather Requirements Test Generate Design Prototypes Design Documents Implementation Write Code

5. Gathering Requirements • Clearly, it drives the whole process • Either implicitly or explicitly, need some statement of problem… • this implies knowledge of domain • AND knowledge of problem in domain • Explicit or Implicit? • So, early or late?

6. Cost to Repair by Phase

7. What is a Requirements Spec? • Statement of problem in the language of the problem domain • Includes: • externalbehaviorof final system • constraints on system • constraints of domain

8. Simple Looking ProblemsSometimesAren’t • Calendar system- • Years, months, weeks, days Is this right? Solar Calendar Years Mon Tue Wed.. Months 1996 1997 1998 1999 2000 Weeks Jan Feb Mar... Days

9. Calendar Taxonomy Solar Calendar 7-Day Calendar Weeks don’t fit in months or years. Really two calendars. Years Containment solves boundary problem. Weeks Months Days

10. Real-World “Simple Problems” • Mutual Exclusion: • Limit access to resource to one simultaneous process at a time • Solutions appear simple, but have deceptive loopholes • See An Investigation of the Therac-25 Accidents [Leveson and Turner] to see what can happen.

11. Client View of Domain • Clients can’t be expected to have rigorous or formal view of domain • Hence, can’t be expected to completely be aware of domain-problem relationship • Some knowledge is explicit • Easier to get at • Some knowledge is implicit • Many constraints are implicit • Hard to get at

12. Requirements Elicitation Process Client Us System SRS Client Domain Problem

13. Communication This process Client Us Requires a common language and common vocabulary. It is up to us to make sure this happens.

14. Communication Problems Common Vocabulary and Dictionary is Required but, not enough • Ambiguity Sources: • Lack of implicit knowledge of domain • Mismatch on meaning of terms (your vocabulary Vs. client’s)

15. Escalator System Requirements Two Signs on Escalator: Shoes Must Be Worn Dogs Must Be Carried Conclusions: You must have on shoes, and you must be carrying a dog. If you have a dog, you have to carry it, so you have to wear all the shoes you carry. If you don’t have a dog, you don’t need to carry it, so you don’t have to wear shoes unless you are carrying some.

16. Start of Elicitation Process • Definition of domain terms • Identification of domain “objects” • Not necessarily “object-oriented programming” objects • Identification of domain functions • Relationship between functions and objects

17. Two Kinds of Elicitation • Client PUSH • “Teach” the client the common language and terms • Help her self-model the domain and problem • Client PULL • Extract the language and terms on the fly

18. Client “Push” • Teach client to model domain • Help them model domain and problem (still in domain terms) • Communication is in model terms • Or teach special ways of “understanding” domain [e.g.. Senge] . • Really, this is teaching a thinking approach

19. Client “Push” Process 1 Modeling Process Client Us Domain knowledge 2 3 4 3 Domain Model SRS Client Domain Problem

20. Modeling Techniques • Just for Real-time: • Finite State Machines • Decision Tables • Program Language Design • StateCharts • Petri Nets • Specification and Description Language • And so on….

21. Client “Pull” • Use Client as information window to domain • Exploratory exchange • Interviews • Prototypes • Observation • Skillfully fill unknown parts of domain and problem • Requires Us to build domain model ourselves

22. Client “Pull” Process 1 “Questions” & Observation Client Us Domain knowledge 2 4 3 SRS Domain/Problem Model Client Domain 4 Problem

23. Reality: • Both Push and Pull • Usually, more Pull than Push • Unless customer is very technical, rigorous and/or formally oriented • So, we need skills to build models ourselves • Danger: Do not prejudge the problem or domain too quickly!!

24. Perspective A C B C B A Connect like letters without crossing lines or leaving box.

25. A C B C B A Early Focus on Constraints • A-A line seems to be constraint • But, is it really? • Need to examine domain and constraints more? • What transforms or shifts would yield easier problem?

26. Change Perspective a Little …and transform A-A constraint A C C B B A

27. Change Perspective a Little …and transform A-A constraint A C C B B A

28. Just to Prove it…. A C B C B A

29. Building Requirements Model(or Theory) • Why? • All other phases of process have step above to compare consistency -- Requirements phase does not. • What? • Formal definition of behavior expected from system. • How? • Attempt ‘Challenges’ or putative theorems against model to see if behavior is reasonable

30. Describe Environment • Describe only ‘environment’ - not system • Why? Avoid implementation bias • Describe Environment ‘as-is’. These constraints are called ‘indicative’ • Often called ‘assumptions’ or ‘constraints’. • Describe Environment as modified by the ‘system’. These are called ‘optative’ • Often called ‘system requirements’

31. Goals and Sub-GoalsSetting the Boundary Invest? Improve Payables Different Business? Maximize Cashflow Recreation? Religion? Drugs? Increase Profits Happy Owner

32. Definitions • All terms need precise definition • Distinguish between Definition and Assertion designation of student must already exist Asserts being a student is the same as being enrolled Defines what a student is, but assumes enrolled

33. Actions • Shared: Both environment and system can observe • Unshared: Only environment can observe • System controlled • Environment controlled There is no system controlled, unshared action

34. Can’t Implement Around Unshared ‘full’ switch Fuel line Flow counter flow Fuel tank unusable fuel Determine when flow will stop (‘empty’) and signal with indicator. ‘Unshared’ without flow counter output.

35. Attempting Challenges Book: bk = (name, phone number pairs) (bill, 555-1212) (judy, 555-1234) (‘‘, EMPTY) Special ‘empty’ designator Operations to manipulate the book: Phone Book AddPhone(bk, nm, pn) (name,#) FindPhone(bk, nm, pn) # DelPhone(bk, nm) (‘‘,EMPTY)

36. First Challenge: FindPhone(AddPhone(bk,Nm,#),Nm) = # Phone Book Phone Book + (Nm,#) AddPhone (Nm, #) FindPhone ‘Nm’ # Should be the same

37. Second Challenge DelPhone(AddPhone(bk, Nm, #), Nm) = bk Phone Book Phone Book + (Nm,#) Phone Book AddPhone (Nm, #) DelPhone Should be the same But, is it?

38. Why This is Wrong Suppose: (Tom, 555-1234) Phone Book Phone Book + (nm,pn) Phone Book AddPhone (nm,pn) DelPhone (Tom,998-7878) “Tom” is now missing The books are different Needed:

39. Using Automata for Constraints Safety: Nothing bad will happen B “A’s are separated by B’s” A Liveness: Something good will happen “After A, there must eventually be a B” A B

40. So, How Do We Actually Use This Stuff?

41. How to Gather Requirements • Map out environment as-is • Map out environment as required • Decide on systems boundaries / goals • List actions with types • Define terms • Construct model • Challenge model • Modify as required

42. Power Window Motor Controller • Cust: We need the window to go up and down in response to a 3-way switch • RE: So, we’re controlling a motor with a momentary contact switch? • Cust: But window stops at top and bottom. • RE: How do we know “top” and “bottom”? • Cust: Stall current, of course. • Cust: Also, releasing switch stops window. • RE: Switch is then in ‘center’? • Cust: Yes.

43. Definitions and Assertions (EOT = End Of Travel) Assertions

44. At Top In Between Stopped At Bottom Known Properties A Safety Property Optative property Top Down, Up A Liveness Property Down Bottom Up Up, Down Moving Indicative properties Center Is this correct?

45. Stopped Better Liveness Spec A Liveness Property Up, Down Moving Center, EOT What About End of Travel? EOT constrained by indicative property (assumption) that window reaches end of travel

46. Indicative Switch Properties Down Up Center Center There is always an ‘up’ or ‘down’ between ‘centers’ and this is constrained by the environment.

47. Window Subsystem Model Motor Down EOT Down At-Top Stop EOT At-Bot Stop Motor Up Up Notice: No ‘up’ from here. Center Down Up Motor Stop Center

48. Initial Challenges • Sequence Down, Center, Down, Center, Up • Seems OK • Sequence Down, EOT • Seems OK • When at top, Up does nothing • Down for 4 sec, center, window stops • Seems OK • When at bottom, Down does nothing Cust: ”Whoops! This isn’t what I want!”

49. Extended Requirements • Cust: I want express down. • RE: Define ‘express down’ • Cust: User holds ‘down’ > 3 seconds • RE: Down only? • Cust: Yes. • RE: So, ‘down’>3 sec + ‘center’ means window to bottom. • Cust: Yes.

50. Control With Express Motor Down EOT Down At-Top Stop Motor Up 3 Sec EOT Motor Down Xpress Center Down EOT Up At-Bot Stop Motor Stop Up Center