Introduction to Requirements Engineering

Tom Kelliher, CS 319

Sept. 7, 1998

Announcements:

From last time:

1. Introduction.

2. SE models.

3. The notion of risk.

Outline:

1. Introduction to requirements engineering.

2. RE process.

3. Software requirements document.

4. Requirements validation.

5. Requirements evolution.

6. Applications.

Assignment: Read Chapter 7. Overview the following software requirements specification:
http://www-nmimc.med.navy.mil/meprs/EASIVReq/srs2_2fin.html
--- EAS IV Functional Requirements

Introduction to Requirements Engineering

System requirements should specify what, not how. Why?

1. Solution should not be pre-defined.

2. Requirements should allow for a wide range of proposed alternative solutions.

Definitions:

1. Requirements definition: Customer generated, natural language document. Enumerates system services and constraints. Audience: client, contractor management, end-users.

2. Requirements specification: Contractor generated, structured document setting out system services in detail. Audience: client, contractor technical staffs. May serve as the contract.

3. Software specification: Abstract, architectural description of the system software. Basis for design and implementation. Internal to contractor.

4. ``Wicked'' problems.

Requirements Engineering Process

Impossible to define a complete and consistent set of requirements:

1. New systems improve upon old systems. Impossible to predict effect of a new system upon an organization.

2. Large systems serve a diverse community. Each person has different requirements and priorities. System requirements are a compromise.

3. End-users often don't write the system requirements. Business decisions influence the design, to the detriment of end-user needs.

Process stages:

1. Feasibility study: Quick and dirty evaluation to determine if current technology (COTS, etc.) can solve the problem. Cost effectiveness.

2. Requirements analysis: Derive system requirements through study of existing systems, user interviews, task, analysis, etc.

3. Requirements definition: Write-up the analysis results.

4. Requirements specification: Create a detailed and precise set of system requirements. Can be done in parallel with high-level system design. Correct errors.

Software Requirements Document

Should satisfy:

1. Specify external system behavior.

2. Specify implementation constraints.

3. Easy to change.

4. Serve as reference for system maintainers.

5. Record forethought about the system life cycle.

6. Characterize acceptable responses to undesired events.

A generic structure for the document:

1. Introduction. Why and, briefly, what.

2. Glossary. Make no assumptions.

3. System models. Show relationships between system, components, environment.

4. Functional requirements definition. Services provided.

5. Non-Functional requirements definition. Constraints and restrictions.

6. System evolution. Fundamental assumptions and anticipated changes.

7. Requirements specification. More detail. Appendix.

8. Hardware. Appendix

9. Database. Logical organization of data. Appendix.

10. Indices.

Requirements Validation

Errors are expensive.

To be checked:

1. Validity. What functionality do the users need?

2. Consistency. Requirements should not contradict.

3. Completeness. All user needed functions should be included.

4. Realism. Don't expect miraculous technological advances.

Some validation mechanisms:

1. Expressing requirements in a formal notation.

2. Prototyping.

3. Requirements reviews.

Requirements Evolution

1. Enduring requirements.

2. Volatile requirements.

Applications

1. Why is it important to distinguish between a definition and a specification?

2. Who should be involved in a requirements review? Why?

3. Rewrite the following requirements so that they may be objectively validated:
   1. The software system should provide acceptable performance under maximum load conditions.

   2. If the system should fail in operation, there should be minimal loss of data.

   3. Structured programming should be used for program development.

4. What ``wicked'' problems can you think of?

5. Consider a system to manage a hospital. Give examples of enduring and volatile requirements.

6. How does the structure of the EAS IV document compare to the structure outlined here?

7. 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?