1. Software Requirements Thomas Alspaugh ICS 221 2002 Nov 5

2. Context “The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements … No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later.” -- Fred Brooks, The Mythical Man-Month

3. What are requirements? Everything that must be true about the software in order for it to be acceptable And nothing else “What” but not “how” Properties of the software Or, a model to be duplicated

4. Why produce requirements? To decide precisely what is to be built To record hard-earned results To communicate with others  Stakeholders  Development team  Documenters  Marketing, legal, regulators … To have a contract To form a basis for testing and acceptance Because not having them can be even more costly

5. What is the cost? Increased likelihood of a development catastrophe  No product at all Failure to meet goals  An unsatisfactory product  A product that is too late  A product that cost too much Inefficiency  $1 if found and fixed during RE phase, $100-200 if found and fixed in maintenance

6. What are the alternatives? Don’t have requirements  Don’t build anything complicated or important  Don’t use a group Have partial requirements  E.g. scenarios or use cases  Postpone some of the pain Develop requirements as you go  Refactor, redesign, recode; hope for consistency Requirements answer questions that must be answered sooner or later

7. How are requirements classified? Functional/nonfunctional  Functional: relates inputs to outputs  Nonfunctional: everything else  Not an especially useful distinction Behavioral/developmental quality  Behavioral: all observable behavior  Developmental quality: not behavior Testability, maintainability, reusability

8. Why are requirements hard? “Essential” vs. “accidental”  Essential difficulties: inherent and unavoidable  Accidental difficulties: not inherent Software requirements involve both kinds

9. Essential difficulties Comprehension  Stakeholders cannot know what they want Communication  Complex, unlike familiar metaphors, arbitrary Control  SW development is hard to control Inseparable concerns  “Everything depends on everything else”

10. Accidental difficulties Written afterwards  … and thus can’t help development Conflicting purposes  Marketing (hyped)  general documentation (unrelated to requirements)  contract (intentionally imprecise) Not expected to be useful  So doesn’t receive appropriate attention and effort Essential properties not present …

11. What semantic properties are desirable for requirements? Complete Internally consistent Precise Not redundant Unambiguous Verifiable

12. What “packaging” properties are desirable for requirements? Readable Modifiable Organized for easy reference Organized for effective review

13. What are some approaches? Scenarios, use cases OO approaches Operational specification SCR (Software Cost Reduction) approach