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)

maintenance and evolution (e.g., requirements)

Characteristics of documentation:accurate and kept currentappropriate for audiencemaintained online (usually)simple but professional in style and appearance

Documentation is expensive --> 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.