1. Software Engineering of Standalone Programs Prof. Ruth Dameron, dameron@colorado.edu Course web site with course materials is under WebCT – Need an identikey and password – Call 303-735-HELP

2. Course web site contents Go to http://webct.colorado.edu/ – Login if you have identikey and user-password Lecture material -- PowerPoint files – Print in “handout” or in Notes format – “Pure black and white” Homework assignments Some additional items such as short articles or book excerpts Other course information – syllabus with reading assignments, holidays – textbook information, PowerPoint lecture files – final exam information – office hours, contact information

3. Part of a whole Software Engineering Certificate -- 9 hrs graduate credit – http://ece.colorado.edu/~swengctf/ – Software Engineering of Standalone Programs – Software Engineering of Multiprogram Systems – Software Engineering of Distributed Systems The links at the above web site point to course materials that are not under control of WebCT. – Their purpose is to let you see what is covered in the 3 courses – Warning: Lecture notes that match the ones I use in class PLUS your homework assignments are the ones that are under WebCT.

4. Requirements Engineering Slides originally developed by Michael Madigan StorageTek Manager, PAL Engineering

5. Cobb’s Paradox "We know why projects fail, we know how to prevent their failure -- so why do they still fail?” Martin Cobb Treasury Board of Canada Secretariat Ottawa, Canada

6. Project Resolution Resolution Type 1 Project Success Resolution Type 2 Challenged Resolution Type 3 Impaired

7. Cost Overruns Percent Over Budget

8. Time Overruns Percent of Time Under Estimated

9. Content Deficiencies Percent of Originally Planned Functionality

10. Project Success Factors Other User Involvemen t Executive Management Support Proper Planning Realistic Expectation Competent Staff Smaller Project Milestones Clear Statement of Requirements Ownership Clear Vision and Objectives Hard-Working Focused Staff

11. Top Ten Project Success Factors 1. user involvement 2. executive management support 3. clear statement of requirements 4. proper planning 5. realistic expectations 6. smaller project milestones 7. competent staff 8. ownership 9. clear vision and objectives 10. hard-working, focused staff

12. Properties of Challenged Projects Lack of Executive Support Other Lack of User Involvement Inc. Requirements & Specs Technology Incompetence Unrealistic Expectation Lack of Resources Changing Requirements & Specs Unclear Objectives Unrealistic Time Frame New Technology

13. Top Ten Challenged Project Factors 1. Lack of user involvement 2. Incomplete requirements and specifications 3. Changing requirements and specifications 4. Lack of executive support 5. Technology Incompetence 6. Lack of Resources 7. Unrealistic expectations 8. Unclear objectives 9. Unrealistic timeframe 10. New technology

14. Properties of Impaired Projects Unrealistic Expectations Lack of Executive Support Lack of Planning Changing Requirements & Specs Other Incomplete Requirement s Lack of User Involvement Lack of Resources Didn’t Need any Longer Lack of IT Management Technology Illiteracy

15. Top Ten Impaired Project Factors 1. Incomplete requirements 2. Lack of user involvement 3. Lack of resources 4. Unrealistic Expectations 5. Lack of executive support 6. Changing requirements & specs 7. Lack of planning 8. Didn’t need anymore 9. Lack of IT management 10. Technology illiteracy

16. Case Studies

17. High Level Software Concepts Model Based (System) Architecture Software Engineering (MBASE) Iterative Development (agile methods)

18. The Model-Clash Spider Web: Master Net 7

19. MBASE Integration Framework 7 Process models Life cycle anchor points Risk management Key practices Success models Business case IKIWISI Stakeholder win-win Property models Cost Schedule Performance Reliability Product models Domain model Requirements Architecture Code Documentation Planning and control Milestone content Evaluation and analysis Process entry/exit criteria Product evaluation criteria

20. What Does a Process Do for You? A software development process gives you The information you need When you need it In a form that you can use – As much or as little as you need – Easy to find what you need

21. Introducing the Rational Unified Process Process Made Practical Proj. Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Disciplines Iterations Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransition Inception Construction Dynamic structure Static structure

22. Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Unified Software Project Management Tools Unified Tools for the Project Team Tools Unified Tools for the Project Team Requirements Management Visual Modeling Automated Testing Content Management Change Management Requirements Management Visual Modeling Automated Testing Content Management Change Management Plan and Execute Iterative Projects Plan and Execute Iterative Projects Measure Progress and Quality Collaborate & Communicate Project Information Collaborate & Communicate Project Information Unified Software Project Management: an integrated solution to deploy, plan, execute, and monitor best practices Tools Unified Tools for the Project Team Tools Unified Tools for the Project Team Requirements Management Visual Modeling Automated Testing Content Management Change Management Requirements Management Visual Modeling Automated Testing Content Management Change Management Plan and Execute Iterative Projects Plan and Execute Iterative Projects Measure Progress and Quality Collaborate & Communicate Project Information Collaborate & Communicate Project Information Select and Deploy Best Practices

23. Requirements Engineering The disciplined application of scientific principles and techniques for developing, communicating, and managing requirements. 6

24. Systems Requirements Engineering Lifecycle User Requirements System Requirements System Architecture User Requirements Component Development Integration Test Acceptance Test System Development Capability Development Component Development

25. Component Development Lifecycle Software Requirements Architectural design Detailed design & coding Integration & Verification User Requirements Component Development

26. Requirements Engineering

27. Requirements Elicitation Software Requirements Identify relevant sources of requirements (usually customer) Determine what information is needed. Analyze the gathered information, looking for implications, inconsistencies, or unresolved issues Confirm your understanding of the requirements with the source Synthesize appropriate statements of the requirements

28. Outcome of good elicitation activities – The buyer/customer fully explore and fully understand their requirements. – The buyer/customers are able to separate their wants from their needs. – The buyer/customers are able to understand the capabilities and limitations of computer technology. – The buyer/customers understand the alternative solutions and impact of each alternative. – The buyer/customers understand the impact of the requirements on the developer and themselves. – The developers are solving the right problem. – The developers have confidence that the system to be delivered is feasible to build. – The developers have the trust and confidence of the customer. – The developers gain domain knowledge of the system

29. Outcome of poor elicitation effort – The customer probably will be dissatisfied. – The customer and developer have to cope with constantly changing requirements. – The developer is solving the wrong problem. – The developer has a difficult time building the system.

30. Requirements Elicitation User Involvement Criteria 2 Other User Involvemen t Executive Management Support Proper Planning Realistic Expectation Competent Staff Smaller Project Milestones Clear Statement of Requirements Ownership Clear Vision and Objectives Hard-Working Focused Staff Project Success Factors Do I have the right user(s)? Did I involve the user(s)early and often? Do I have a quality user(s) relationship? Do I make involvement easy? Did I find out what the user(s) needs? Software Requirements

31. Requirements Analysis Obtain Requirements from all possible sources (include but not limited to): – observation and measurements of the current system – interviews with customers – current system documentation – feasibility studies – models and prototypes – competitive analysis Software Requirements

32. Quality attributes

33. Requirements Specification Software function Performance External Interfaces Design Constraints Quality Attributes Software Requirements

34. Statement of Requirements Criteria Software Requirements Do I have a concise vision? Do I have a functional analysis? Do I have a risk assessment? Do I have a business case? Can I measure the project? Project Success Factors

35. Requirements Verification To identify and resolve software problems and high risk issues early in the software cycle. The assurance that the software requirement specification is in compliance with the system requirements, conforms to document standards, and is an adequate basis for the architectural design. Integration & Verification

36. Requirements Management Basic responsibility is to keep project within costs, within budget, and to meet customers needs. Estimate cost of system based on requirements. Control the volatility of the requirements. Manage the requirements configuration of the system Negotiate requirement changes Re-estimate cost of the system when requirements change. Software Requirements

37. Requirements Engineering Requirements Verification Requirements Analysis Requirements Specification Requirements Management Requirements Elicitation

38. Release 1Release 3Release 2 Requirements Engineering III Requirements Management Requirements Elicitation Requirements Verification Requirements Specification Requirements Management Requirements Analysis Foundation Requirements Elicitation Requirements Verification Requirements Specification Requirements Management Requirements Analysis Foundation Requirements Elicitation Requirements Verification Requirements Specification Requirements Management Requirements Analysis Requirements Elicitation Requirements Verification Requirements Specification Requirements Management Requirements Analysis

39. Successful Release Cycle Proportions 4N months 3N months 2N Months

40. Success Attributes that Requirements Engineering Affect User Involvement Clear Statement of requirements Proper Planning Realistic Expectations Smaller Project Milestones Clear Vision and Objectives Hard Working, Focused Staff Project Success Factors

41. Requirements Engineering Conclusion Software Requirements Architectural design Detailed design & coding Integration & Verification User Requirements Component Development Software Requirements Engineering includes: – elicitation – analysis – specification – verification and validation – management of requirements development process Affects 7 of 10 attributes of successful projects

42. References 1 The Standish Group, Chaos, January 1995 2 The Standish Group, Unfinished Voyages, September 1995 3 Software Quality Measurement for Distributed Systems, RADC-TR-83-175 4 Requirements Engineering, Thayer, SMC 10/97, version 2 5 Richard Thayer, Software Requirements Engineering, IEEE, 1997 6 STEP, Operational Requirements for Automated Capabilities, STEP, 1991 7 MBASE, “Avoiding the Software Model-Clash Spiderweb,” IEEE Computer, November, 2000, pp. 120-122.