Software requirements engineering

Editor's Notes

• #3: Like anything with sw eng, we are trying to solve a problem.
• #4: From Unfinished Voyages. There is a decently well-established set of success criteria. We know how to fix them but why don’t we? Requirements engineering satisfies quite a few of those areas.
• #5: Give background on where the following information came from. Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified. Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified. Resolution Type 3, or project impaired: The project is canceled at some point during the development cycle. Overall, the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (canceled) for 31.1%. They looked at 365 respondents and represented 8,380 applications. They divided them into these categories, small medium and large companies small: less than $100,000 annual revenue large: greater than $500,000,000 medium: in between Included the gamut of applications and companies. Basically, the division was like this regardless of size. Large companies had more impaired than challenged; smaller ones had more challenged than impaired. Perhaps this was because the small company’s life depended on it and they had to deliver SOMEthing. Unfinished Voyages shows that more and more projects fall into challenged and impaired category.
• #6: Three controls we have -- Cost overruns for challenged and impaired projects. Over 50% chance of being over 50% over budget. Time overruns -- 50% chance of being 100% over the time you estimated. Functionality - only 7% of challenged projects deliver the original functionality. 50% chance or more that you are only going to deliver 50% of the originally planned functionality.
• #7: Previous slide’s comments repeated here: Three controls we have -- Cost overruns for challenged and impaired projects. Over 50% chance of being over 50% over budget. Time overruns -- 50% chance of being 100% over the time you estimated. Functionality - only 7% of challenged projects deliver the original functionality. 50% chance or more that you are only going to deliver 50% of the originally planned functionality.
• #8: See comment in notes, two slides ago. Three controls we have -- Cost overruns for challenged and impaired projects. Over 50% chance of being over 50% over budget. Time overruns -- 50% chance of being 100% over the time you estimated. Functionality - only 7% of challenged projects deliver the original functionality. 50% chance or more that you are only going to deliver 50% of the originally planned functionality .
• #9: One of the best things that came out of Chaos was the top ten reasons that made projects successful. Requirements engineering includes: (the list is on the next slide) 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 If you have all of these, high probability of success.
• #11: These correlate well as the opposite of the success 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
• #13: Almost the same list as “challenged” except for a greater emphasis on incomplete requirements and lack of user involvement. 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
• #15: Standish Group examined case studies. 1 California DMV automation of the driver’s license. The only one they met was realistic expectations. They didn’t get users involved, etc. The hardware and software didn’t work on the same system. $150M down the drain. American Airlines Early in 1994, American Airlines settled their lawsuit with Budget Rent-A-Car, Marriott Corp. and Hilton Hotels after the $165 million CONFIRM car rental and hotel reservation system project collapsed into chaos. This project failed because there were too many cooks and the soup spoiled. Executive management not only supported the project, they were active project managers. Of course, for a project this size to fail, it must have had many flaws. Other major causes included an incomplete statement of requirements, lack of user involvement, and constant changing of requirements and specifications. Hyatt Hotels While Marriott and Hilton Hotels were checking out of their failed reservation system, Hyatt was checking in. Today, you can dial from a cellular airplane telephone at 35,000 feet, check into your Hyatt hotel room, schedule the courtesy bus to pick you up, and have your keys waiting for you at the express desk. This new reservation system was ahead of schedule, under budget, with extra features -- for a mere $15 million of cold cash. They used modern, open systems software with an Informix database and the TUXEDO transaction monitor, on Unix-based hardware. Banco -- wanted to consolidate acquired banks’ banking systems into one system, approximately 19 systems. Had the criteria and were on time, on budget, and delivered. They used a prototyping technique rather than written SOR.
• #17: SYSTEMS Requirements Engineering Lifecycle Components may be hardware, may be software, may be sub-systems, may be smaller Talk through the arrows while mouse-clicking In incremental development, which portions of this “lifecycle” are executed?
• #18: In incremental development, which items are executed in an increment? How many times?
• #19: These are the five activities involved in software requirements engineering. Given what’s been said about incremental development, it should be obvious by now that these are all done throughout the project on various requirements.
• #20: Identify relevant sources of requirements: What are sources of requirements? customer -- various roles are all “the customer” maintenance test strategic planning for product family ease of demo etc. Analyze gathered information -- we’ll look at various techniques to highlight inconsistencies, missing items Confirm your understanding -- this step is done in various ways with various development methods. For example in various agile methods, there is an emerging product available to demo at the end of each increment. Synthesize appropriate statements
• #22: Requirements may change anyway -- but if the elicitation was done poorly, they will change constantly as you gradually understand each other, rather than changing for less frequent reasons such as market influences.
• #23: Getting the right requirements absolutely requires talking to the right users. Need to have ongoing relationship with the users, make them feel their input and time and trouble really made a difference in your findings. Must make a difference between the needs and wants. Sometimes you don’t know until the crisis happens. Takes skill to find what the real problem is and solve it in a way that allows them to do their job.
• #24: Software Quality Attributes and Metrics 3 Correctness - Extent to which a program satisfies its specifications and fulfills the user’s mission objectives. Reliability - Probability that the software will perform its logical operation in the specified environment without failure. Efficiency - Degree of utilization of resources in performing functions. Integrity - Extent to which unauthorized access to the software or data can be controlled. Usability - Effort for training and software operation - familiarization, input preparation, execution, output, interpretation. Survivability - Probability that the software will continue to perform or support critical functions when a portion of the system is inoperable. Maintainability - Average effort to locate and fix a software failure. Verifiability - Effort to verify the specified software operation and performance. Portability - Effort to convert the software for use in other operating environments. Reusability - Effort to convert a software component for use in another application. The analysis group has a tough task to take the huge picture of data and whittle down to the first 12 months without precluding possibility of the big picture over time. Analysis process generates more questions which requires going back to the customer. More efficient for analysts to go to customer rather than elicitation team redoing a part.
• #25: Correctness - Extent to which a program satisfies its specifications and fulfills the user’s mission objectives. Reliability - Probability that the software will perform its logical operation in the specified environment without failure. Efficiency - Degree of utilization of resources in performing functions. Integrity - Extent to which unauthorized access to the software or data can be controlled. Usability - Effort for training and software operation - familiarization, input preparation, execution, output, interpretation. Survivability - Probability that the software will continue to perform or support critical functions when a portion of the system is inoperable. Maintainability - Average effort to locate and fix a software failure. Verifiability - Effort to verify the specified software operation and performance. Portability - Effort to convert the software for use in other operating environments. Reusability - Effort to convert a software component for use in another application. The analysis group has a tough task to take the huge picture of data and whittle down to the first 12 months without precluding possibility of the big picture over time. Analysis process generates more questions which requires going back to the customer. More efficient for analysts to go to customer rather than elicitation team redoing a part.
• #26: Considerations for use of a Requirements Specification Standard. Why use a standard at all? Allow consumers and verification agents the ability to determine if the requirement specification meets their needs easier. The ability to repeat the process again. Should IEEE 830-93 be used? If there is nothing currently in place absolutely. There has been a great deal of time and effort by requirements professionals developing the standard. There should be a great deal of effort to avoid re-inventing the wheel. (Design constraints -- explicitly tells why must be done a certain way.)
• #27: For all of the success criteria, Unfinished Voyages report (which is a followup to the Chaos report) asked five questions to allow you to evaluate whether you are meeting the success criteria. Here’s my Requirements Specification -- which ones are risky? Probably the ones you have never done before because you may not have the right staff with the right competence. In requirements engineering, we are showing progress as one measure of the project. Requirements engineering is intertwined with project management.
• #28: You want to make sure that people can really use the requirements specification before you throw it over the wall to the developers. Many people involved in this don’t know when they are done. To identify and resolve sw problems and high risk issues early in the software cycle. early in the software cycle early in each increment and so ad infinitum
• #29: This is essential to the project manager being able to do the job of project management. With the requirements specification, you can do the kinds of things the project manager needs to be able to do -- cost estimation, etc. Once it’s been approved, there must be real proof that a change is necessary. (Consider cost as time impact on delivery date.) From “control the volatility” down to re-estimation -- those tasks need to be rolled into configuration management (change management).
• #30: This is an overall framework, not a methodology , for categorizing activities and showing progress. Requirements Elicitation : The process through which the customers and the developer of a software system discover, review, articulate, and understand the users’ needs and the constraints on the software and the development activity. 5 Requirements Analysis : The process of analyzing the customers’ and users’ needs to arrive at a definition of software requirements. 5 Requirements Specification : The development of a document or set of documents that clearly and precisely records each of the requirements of the software system. 5 Requirements Verification : The process of ensuring that the software requirements specification is in compliance with the system requirements, conforms to document standards of the requirements phase, and is an adequate basis for the architectural (preliminary) design phase. 5 Requirements Management: The planning and controlling of the requirements elicitation, specification, analysis, and verification process. 5 Three main activities drive the work. Validation and management support the three main ones. One team moves thru phases of the three main activities. Re-emphasize: This is an overall framework, not a methodology , for categorizing activities and showing progress.
• #31: It is important to deliver concentric circles of functionality where one circle is the foundation for the next release. With each circle, need to go back and validate that the requirements are correct. Requirements have a half life so you need to confirm that old requirements are still requirements.
• #32: If you try to deliver the project on 2 year boundaries, you tend to be a year late. So much stuff got put into that, expected to absorb so much, the 24 month original window became 36 months. Rule of thumb, after requirements are approved, first release should be 2*N units out and then add functionality every N units after that. In order to do this, you MUST prioritize the requirements into buckets. P1 -- without this, it is not sellable. P2 -- critical P3 -- important/should have P4 -- nice to have
• #33: What is NOT on that list from the top ten? 2. executive management support 4. proper planning 5. realistic expectations 6. smaller project milestones 9. clear vision and objectives 10. hard-working, focused staff -- requirements enable staff to focus and proceed; no interruptions or re-directions during an increment
• #34: Summary -- it’s these five things.