Software Requirements Thomas Alspaugh ICS Nov 5

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

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

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

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, $ if found and fixed in maintenance

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

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

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

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”

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 …

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

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

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