Requirements Definition and Specification
Tom Kelliher, CS 319
Sept. 27, 2000
Read Chapter 12. (Surveying major portions of text.)
Lists of rough tasks by 10/2.
Requirements engineering.
- Introduction.
- Requirements definition. Use of templates.
- Requirements specification. Traceability. Structured language
specification. Design Description Languages.
- Non-Functional requirements.
Software Design.
- Importance of specification in client/contractor relationship.
- Specification stages: description specification, formal
specification.
- 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,
user.
Requirements are of two types:
- 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,
standards, etc.
Distinguishing between functional and non-functional requirements can be
difficult.
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:
- Lack of clarity: preciseness vs. conciseness.
- Requirements confusion: distinctions not drawn between functional
requirements, non-functional requirements, system goals, and design
information.
- 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:
- Ambiguous meanings of words.
- Over-Flexible, leading to redundant requirements.
- Ineffective partitioning of requirements.
A few solutions: structured natural language, design description languages.
Cross-referencing needed:
- Assign a unique number.
- Explicitly identify related requirements by number.
- Cross-reference matrix.
For each requirement:
- Name and description.
- Inputs, outputs. What, where?
- Other required entities.
- Pre-conditions, post-conditions, side-effects.
May still be ambiguous.
- Pseudo-programming language. Abstract concepts added.
- Useful when a service is described as a sequence of steps.
- Useful for interface design.
Might intimidate customer. Might be interpreted as design model.
Define system properties and constraints.
Types:
- Product: reliability, performance, etc.
- Process: Standards, implementation, etc.
- External: ethics, interoperability, etc.
Requirements must be verifiable. Consider, ``The system must be easy to
learn.''
Possibility of conflicts.
Exercises:
- 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 dairy confections frozen.
- Problem 7.8.
- Problem 7.9. Which types of requirements will depend upon which
types of requirements?
- Problem 7.10.
Thomas P. Kelliher
Tue Sep 26 07:51:38 EDT 2000
Tom Kelliher