Software Requirements

1
Software Requirements

• Thomas AlspaughICS 2212002 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?

• Dont have requirements
• Dont build anything complicated or important
• Dont 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 cant help development
• Conflicting purposes
• Marketing (hyped)
• general documentation (unrelated to requirements)
• contract (intentionally imprecise)
• Not expected to be useful
• So doesnt 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