SWE 513: Software Engineering

1
SWE 513 Software Engineering
Requirements II
2
Details in Requirements
Requirements must be specific Examples --
university admissions system Requests for
information received by email must be answered
within one business day. An admissions officer
who is talking to an applicant by telephone must
be able to retrieve the applicant's records
within 10 seconds. No financial aid offer may
exceed the maximum defined in Section 8.7.
3
Documentation
Reasons for documentation visibility (e.g.,
project plan, interim report) user
support (e.g., user manual) team
communication (e.g., interface specifications) ma
intenance and evolution (e.g., requirements)
Characteristics of documentation accurate and
kept current appropriate for audience maintained
online (usually) simple but professional in
style and appearance Documentation is expensive
--gt Quality not volume
4
Requirements Specification Purpose
1. Document that describes the requirements to
the stakeholders in a precise manner Expressed
in the terms that the stakeholders understand
As precise and specific as possible
Comprehensible from many viewpoints Reviewed
by stakeholders so that they understand
implications Must be clear about assumptions
(things left out)
5
Requirements Specification Purpose
2. It describes the requirements to the
implementers As precise and specific as
possible Expressed in terms that they
understand Comprehensible to new team members
6
Requirements Specification Purpose
3. It records the requirements for the future
An essential part of system evolution 4. If may
be a contractual document
7
Requirements Specification Process
The client must understand the requirements
specification. Do not assume that anybody
has read a document. Do not assume that
anybody understands a document. Go through the
requirements specification with the client, line
by line. It is usual for the client and
developer to sign the requirements document when
it is agreed. Compare with the plans to build a
house. This is the specification of the system
that you are about to build.
8
Requirements Analysis v. System Design
Dilemma. Requirements analysis should make
minimal assumptions about the system design.
But the requirements definition must be
consistent with computing technology and the
resources available. In practice, analysis and
design are interwoven. However 1. Do not to
allow the requirements analysis to prejudge the
system design. 2. Do not allow assumptions about
the design to have influence the requirements
analysis.