Introduction to Requirements Engineering
Tom Kelliher, CS 319
Sept. 18, 2000
Use of class time for project work.
Read Chapter 7. Overview the following for examples of software
Electronic workbook, Brooks wrap-up.
- Introduction to requirements engineering.
- RE process.
- Software requirements document.
- Requirements validation.
- Requirements evolution.
Requirements definition and specification.
System requirements should specify what, not how. Why?
- Solution should not be pre-defined.
- Requirements should allow for a wide range of proposed alternative
Note the diverse audiences. These documents cannot be too narrow.
- Requirements definition: Customer generated, natural language
document. Enumerates system services and constraints. Audience: client,
contractor management, end-users.
- Requirements specification: Contractor generated, structured document
setting out system services in detail. Audience: client, contractor
technical staffs. May serve as the contract.
- Software specification: Abstract, architectural description of the
system software. Basis for design and implementation. Internal to
- ``Wicked'' problems.
Impossible to define a complete and consistent set of requirements:
- New systems improve upon old systems. Impossible to predict effect
of a new system upon an organization.
- Large systems serve a diverse community. Each person has different
requirements and priorities. System requirements are a compromise.
- End-users often don't write the system requirements. Business
decisions influence the design, to the detriment of end-user needs.
- Feasibility study: Quick and dirty evaluation to determine if current
technology (COTS, etc.) can solve the problem. Cost effectiveness.
- Requirements analysis: Derive system requirements through study of
existing systems, user interviews, task, analysis, etc.
- Requirements definition: Write-up the analysis results.
- Requirements specification: Create a detailed and precise set of
system requirements. Can be done in parallel with high-level system
design. Correct errors.
- Specify external system behavior.
- Specify implementation constraints.
- Easy to change.
- Serve as reference for system maintainers.
- Record forethought about the system life cycle.
- Characterize acceptable responses to undesired events.
A generic structure for the document:
- Introduction. Why and, briefly, what.
- Glossary. Make no assumptions.
- System models. Show relationships between system, components,
- Functional requirements definition. Services provided.
- Non-Functional requirements definition. Constraints and
- System evolution. Fundamental assumptions and anticipated changes.
- Requirements specification. More detail. Appendix.
- Hardware. Appendix
- Database. Logical organization of data. Appendix.
Errors are expensive.
To be checked:
- Validity. What functionality do the users need?
- Consistency. Requirements should not contradict.
- Completeness. All user needed functions should be included.
- Realism. Don't expect miraculous technological advances.
Some validation mechanisms:
- Expressing requirements in a formal notation.
- Requirements reviews.
- Enduring requirements.
- Volatile requirements.
- Why is it important to distinguish between a definition and a
- Who should be involved in a requirements review? Why?
- Rewrite the following requirements so that they may be objectively
- The software system should provide acceptable performance under
maximum load conditions.
- If the system should fail in operation, there should be minimal
loss of data.
- Structured programming should be used for program development.
- What ``wicked'' problems can you think of?
- Consider a system to manage a hospital. Give examples of enduring
and volatile requirements.
- How do the structures of the example SRS documents compare to the
structure outlined here?
- While studying a requirements document, you discover a significant
requirements conflict which you know would be expensive to correct after the
system has been implemented. You point this out to the system customer who
rejects your arguments after what you think is a superficial analysis. You
are confident that your technical decision is correct. What should you do?
Thomas P. Kelliher
Fri Sep 15 10:09:11 EDT 2000