Requirements Definition and Specification
Tom Kelliher, CS 319
Sept. 11, 1998
From last time:
- Requirements engineering.
- Requirements definition. Use of templates.
- Requirements specification. Traceability. Structured language
specification. Design Description Languages.
- Non-Functional requirements.
Assignment: Project pitch, group meetings.
- Importance of specification in client/contractor relationship.
- Specification stages: description specification, formal
- Requirements specification vs. software specification.
- Abstract description of system services and constraints.
- Defines the external behavior --- not internal design.
- It should not specify an implementation model.
- Written in natural language so that it is understood by managers,
Requirements are of two types:
Distinguishing between functional and non-functional requirements can be
- 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.
- Non-Functional requirements --- constraints on the services a system
provides: speed, space, cost, development process, development tools,
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
- Lack of clarity: preciseness vs. conciseness.
- Requirements confusion: distinctions not drawn between functional
requirements, non-functional requirements, system goals, and design
- Requirements amalgamation: multiple unique requirements expressed as
a single requirement.
- Use a standard form to ease checking.
- Number and cross-reference.
- Bold, italic.
- One requirement at a time.
- Group related requirements.
- Provide rationale (important later).
Problems with natural language specifications:
A few solutions: structured natural language, design description languages.
- Ambiguous meanings of words.
- Over-Flexible, leading to redundant requirements.
- Ineffective partitioning of requirements.
- Assign a unique number.
- Explicitly identify related requirements by number.
- Cross-reference matrix.
For each requirement:
May still be ambiguous.
- Name and description.
- Inputs, outputs. What, where?
- Other required entities.
- Pre-conditions, post-conditions, side-effects.
Might intimidate customer. Might be interpreted as design model.
- Pseudo-programming language. Abstract concepts added.
- Useful when a service is described as a sequence of steps.
- Useful for interface design.
Define system properties and constraints.
Requirements must be verifiable. Consider, ``The system must be easy to
- Product: reliability, performance, etc.
- Process: Standards, implementation, etc.
- External: ethics, interoperability, etc.
Possibility of conflicts.
- Write five requirements for the business end of a writing
instrument. Identify each as functional or non-functional.
- Repeat for a device which keeps frozen confections frozen.
- Problem 7.8.
- Problem 7.9. Which types of requirements will depend upon which
types of requirements?
Thomas P. Kelliher
Wed Sep 9 21:09:33 EDT 1998