Requirements are descriptions of what the system should and should not do, the service it provides, and the constraints on its operation
Enable developers to make software that wil correctly fulfil customers needs
Provides a basis for tests, validation and verification
Enable (semi-)cost accurate specification
Important to distinguish what is built from how it is built
Requirements act as a bridge between customers and developers
First stage in any process is software specification - requirements engineering
Requires that we define the services required from the system
Identify constraints on operation and development
Produce a requirements document
End user facing and system developer facing - possibly two documents
Feasibility study determines that task is feasible and cost effective
Requirements elicitation and analysis derives the system requirements
Look at existing docs
Talk to customer
Discuss features
Possibly prototype
Requirements specification translates information gathered in elicitation into formal documents
Requirements validation ensures requirements are achievable and valid
Need to ensure customer signs off requirements
Notion of C- and D-requirements for customer and development facing
Technical requirements vs idiot speak
C-requirements describe operation and constraints from users's point of view
D-facing give detailed description of system functions, acting as basis for contract with developer
Good requirements are
Prioritised: features have an implementation priority
Consistent: requirements do not conflict with each other
Modifiable: able to revise set of requirements when necessary and maintain history of changes
Traceable: able to link each requirement to source, which could be higher-level requirement, use case, or customer statement
Correct: accurately describes functionality to be delivered
Feasible: must be possible to implement each requirement within the known capabilities and limitations of environment
Necessary: should document something that customers actually need, or is required for conformance to external standard or interface
Unambiguous: someone reading requirement should interpret it only one way
Verifiable: can tests or other approaches be used to verify if requirement has been implemented properly
MoSCoW requirements group requirements into 4 groups:
Must have
Should have
Could have
Won't have
Requirements document will be read by:
Customers
Managers
Engineers
Testers
Maintainers
Sections include:
Preface - history and purpose of document
Intro - justify and outline system
Glossary
User requirements design - describe services provided for users
System architecture - high-level overview of system
Requirements spec - describe functional and non-functional requirements
System models - show relationships between system components
System evolution - anticipated changes due to changing future needs
Functional requirements describe what system should do, state system services and how it should behave in different scenarios
Non-functional requirements are constraints on services or functions offered by system, describe qualities of the system such as availability, performance, etc
Requirements engineering processes is not a linear sequence, processes often interleaved and iterated upon
Requirements discovery
Gather info from stakeholders
Domain research
Consider use cases
Classification and organisation - group similar requirements and organise into categories
Prioritisation and negotiation - assign priorities and sort conflicts between requirements from different stakeholders
Specification - write the document and give to stakeholders, then iterate
Requirements validation is key once document has been written
Validity - will system support customer's needs?
Consistency - are there any conflicts?
Realism - can system be produced with available resources and technology?
Verifiability - can system be shown/proved to satisfy requirements?
Review by both customers and engineers
Prototyping and test-case generation
Requirements must be managed to see if they should be accepted
Problem analysis - is new requirement valid and unambiguous?
Change analysis - what are the effects on the rest of the system?
Change implementation - do the change
Must take into account legal, social, ethical, professional issues
Copyright
Patents
Developers given fair recognition of work
Software not produced to do anything illegal or evil