Lecture Notes for
Software Engineering Concepts
The Requirements
Process, 24 January 2000
- srs uses
- a
common document among differing views - customer, developer, user
- help the client clarify the problem
- a basis for the
agreement among client and developer
- a reference for the
produced system
- the first shot at error detection and
correction
- srs errors do occur because the srs is
difficult
- srs errors tend to be end-to-end
- the cost to
fix errors increases with discovery time
- early investments in
srs error detection and correction pay off
- late error detection
induces change
- changes increase development time and cost
- comitting the resources to providing a requirements process
- requirements process
- context dependent,
hardware and software
- software only
- three subphases:
analysis, specification, validation
- overall process is
iterative and overlapping
- much feedback passes among the
sub-phases
- principle analysis tools: divide and conquer and
abstraction
- principle specification tools: structural
formalisms
- the relation between requirements analysis and
system design: similar tools different objectives
- levels of
abstraction - when too much what becomes how
- lower levels of
abstraction tend toward the how
- customer's hows should come at
the lower levels of the srs
This page last
modified on 24 January 2001.