Requirements Definition and Specification

Tom Kelliher, CS 319

Sept. 11, 1998

Announcements:

From last time:

1. Requirements engineering.

Outline:

1. Introduction.

2. Requirements definition. Use of templates.

3. Requirements specification. Traceability. Structured language specification. Design Description Languages.

4. Non-Functional requirements.

Assignment: Project pitch, group meetings.

Introduction

1. Importance of specification in client/contractor relationship.

2. Specification stages: description specification, formal specification.

3. Requirements specification vs. software specification.

Requirements Definition

1. Abstract description of system services and constraints.

2. Defines the external behavior --- not internal design.

3. It should not specify an implementation model.

4. Written in natural language so that it is understood by managers, user.

Requirements are of two types:

1. Functional requirements --- the services a system should provide, what the system should do in response to particular inputs, what the behavior is in particular situations. Sometimes will explicitly state what system should not do.

   Need for consistency, completeness.

2. Non-Functional requirements --- constraints on the services a system provides: speed, space, cost, development process, development tools, standards, etc.

Example: consider a requirements defn. for a ``writing instrument.'' Is the requirement ``Marks left by the instrument shall be erasable'' functional or non-functional? How about ``The instrument shall leave a uniform mark upon the writing surface?'' ``The user should be able to vary the width of the mark.'' Do we have one requirement per statement? Do any contradict?

Other difficulties:

1. Lack of clarity: preciseness vs. conciseness.

2. Requirements confusion: distinctions not drawn between functional requirements, non-functional requirements, system goals, and design information.

3. Requirements amalgamation: multiple unique requirements expressed as a single requirement.

Requirements Template

1. Use a standard form to ease checking.

2. Number and cross-reference.

3. Bold, italic.

4. One requirement at a time.

5. Group related requirements.

6. Provide rationale (important later).

Requirements Specification

Problems with natural language specifications:

1. Ambiguous meanings of words.

2. Over-Flexible, leading to redundant requirements.

3. Ineffective partitioning of requirements.

Traceability

Cross-referencing needed:

1. Assign a unique number.

2. Explicitly identify related requirements by number.

3. Cross-reference matrix.

Structured Language Specifications

For each requirement:

1. Name and description.

2. Inputs, outputs. What, where?

3. Other required entities.

4. Pre-conditions, post-conditions, side-effects.

Design Description Languages

1. Pseudo-programming language. Abstract concepts added.

2. Useful when a service is described as a sequence of steps.

3. Useful for interface design.

Non-Functional Requirements

Define system properties and constraints.

Types:

1. Product: reliability, performance, etc.

2. Process: Standards, implementation, etc.

3. External: ethics, interoperability, etc.

Possibility of conflicts.

Applications

Exercises:

1. Write five requirements for the business end of a writing instrument. Identify each as functional or non-functional.

2. Repeat for a device which keeps frozen confections frozen.

3. Problem 7.8.

4. Problem 7.9. Which types of requirements will depend upon which types of requirements?

5. 7.10.