1. CS351 © 2003 Ray S. Babcock Requirements What not How “The Pizza Experiment” 1994, 350 companies, 8000 software projects. 31% were canceled before they were completed In large companies, 9% were delivered on time and cost what they were budgeted. In small companies, 16%

2. CS351 © 2003 Ray S. Babcock Causes Of Failed Projects 1. Incomplete requirements (13.1%) 2. lack of user involvement (12.4%) 3. lack of resources (10.6%) 4. unrealistic expectations (9.9%) 5. lack of executive support (9.3%) 6. changing requirements and specifications (8.7%) 7. lack of planning (8.1%) 8. system no longer needed (7.5%)

3. CS351 © 2003 Ray S. Babcock Notice Some part of the requirements elicitation, definition, and management process is involved in almost all of these causes. 1. Requirements that absolutely must be met. 2. Requirements that are highly desirable but not necessary. 3. Requirements that are possible but could be eliminated.

4. CS351 © 2003 Ray S. Babcock What Not How Use Cases How should the system respond to specific users with a specific role. User's manual. Outputs, Inputs, Process mock-ups

5. CS351 © 2003 Ray S. Babcock Types Of Requirements Physical Environment Interfaces Users and Human Factors Functionality Documentation Data Resources Security Quality Assurance

6. CS351 © 2003 Ray S. Babcock Sources For Requirements Stakholder wants and needs Domain models Current situation model Reusable Requirements Suggested Types of Requirements Existing documents Current organization and systems

7. CS351 © 2003 Ray S. Babcock Requirement Steps Review the current situation. Apprentice with the user to understand context, problems, and relationships. Interview current and potential users. Make a video to show how the new system might work. Dig through existing documents. Brainstorm with current and potential users. Observe structures and patterns.

8. CS351 © 2003 Ray S. Babcock Characteristics Of Requirements Correct Consistent Complete Realistic Needed Verifiable (testable) Traceable

9. CS351 © 2003 Ray S. Babcock Expressing Requirements Static Descriptions Indirect Reference Recurrence Relations Axiomatic Definition Expressions as a Language (BNF) Data Abstraction Abstract Data Type (cs210 slides)

10. CS351 © 2003 Ray S. Babcock cont. Dynamic Descriptions Decision Tables Functional Descriptions Transition Diagrams Finite State Machine Event Tables Petri Nets

11. CS351 © 2003 Ray S. Babcock Plain old English I like just writing careful requirements in English. Readable by both customers and developers. Easily stored and edited.

12. CS351 © 2003 Ray S. Babcock Object Oriented Specification What data structures define an entity? How does an entity's state evolve over time? What aspects of entities and processes are persistent over time? Object, method, operation, encapsulation, class hierarchies, multiple inheritance.

13. CS351 © 2003 Ray S. Babcock Additional Requirements Notations Hierarchical Techniques : Warnier diagram Data Flow Diagrams Software Requirements Engineering Methodology Structured Analysis and Design Technique Formal Languages (Z)

14. CS351 © 2003 Ray S. Babcock Prototyping Throw away prototype. Evolutionary prototype. Rapid prototyping.

15. CS351 © 2003 Ray S. Babcock First Interface prototype Enter year: ____________ Enter month: __________ Enter day: ____________

16. CS351 © 2003 Ray S. Babcock Second Interface prototype July 1998 1 2 3 4 5 6 7 8 9 10 11... (calendar page)

17. CS351 © 2003 Ray S. Babcock Third Interface prototype 1998 ---------------|----------------------- 2025 1------------------------------|--------------31 Jan ------------|---------------------------Dec [ Tues 16 October 2002]

18. CS351 © 2003 Ray S. Babcock Level Of Specification An Australian study reported the results of a survey or problems with requirements. uneven level of specification different writing styles difference in experience among analysts different formats and writing styles mixing requirements with partial solutions often over-specified (specific computers)

19. CS351 © 2003 Ray S. Babcock cont. under specified (especially when describing the operating environment, maintenance, simulation for training, administrative computing and fault tolerance. Recommendations: 1. Each clause should contain only one requirement. 2. Avoid having one requirement refer to another requirement. 3. collect like requirements together.

20. CS351 © 2003 Ray S. Babcock Specifications Specification IEEE Michael will have these available soon.

21. CS351 © 2003 Ray S. Babcock The Requirements Document Many formats, but some common themes. Each requirement numbered. Figures numbered and labeled. New sections start on a new page. More later......

22. CS351 © 2003 Ray S. Babcock How developers see users Users don't know what they want. Users can't articulate what they want. Users have too many needs that are politically motivated. Users want everything right now. Users can't prioritize needs. Users refuse to take responsibility for the system. Users are unable to provide a usable statement of needs Users are not comitted to system development project. Users are unwilling to compromise. Users can't remain on schedule.

23. CS351 © 2003 Ray S. Babcock How Users See Developers Developers don't understand operational needs. Developers place too much emphasis on technicalities. Developers try to tell us how to do our job. Developers can't translate clearly stated needs into a successful system. Developers say no all the time. Developers are always over budget. Developers are always late. Developers ask users for time and effort, even to the detriment of the user's important primary duties.

24. CS351 © 2003 Ray S. Babcock cont. Developers set unrealistic standards for requirements definition Developers are unable to respond quickly to legitimately changing needs.

25. CS351 © 2003 Ray S. Babcock Requirements Validation The process of determining that the specification is consistent with the requirements definition; that is, validation makes sure that the requirements will meet the customer's needs. Requirement Review

26. CS351 © 2003 Ray S. Babcock Critera Applicability Implementability Testability/simulation Checkability Maintainability Modularity Level of Abstraction/expressibility Soundness Verifiability Run-Time safety

27. CS351 © 2003 Ray S. Babcock cont. Tools maturity Looseness Learning Curve Technique Maturity Data Modeling Discipline