Requirements Engineering

Overview

To frame our discussion, consider:

What is the nature of software requirements?

How are requirements determined?

OUTLINE

  1. What are requirements?
  2. Importance of Requirements
  3. Requirements Engineering

What are requirements?

Definitions

A statement of a system service or constraint.

A condition or capability needed by a user to solve a problem or achieve an objective. (IEEE-610)

Example

1. The system shall maintain records of all library materials including books, serials newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disk and CD-ROMs.

Sets out in broad terms what the system should do.

2. The system shall allow users to search for an item by title, author, or ISBN.

Define system functionality.

3. The user interface shall be implemented using a World-wide Web browser.

State how the system must be implemented.

4. The system shall support at least 20 transactions per second.

Specify a minimum acceptable performance criteria.

5. The system facilities, available to public users, shall be demonstrable in 10 minutes or less.

Specify usability requirements in quantitative terms.

Requirements

Requirements describe:

User-level behaviors or functionality (features)
General system properties
Definitions of other systems which must be integrated
Specific operational constraints
Domain rules (e.g., computation)
Development constraints

A requirement is a specification of what a system must do -- the things about the system users can observe.

Behavioral Requirements (Functional) define what the system does. These describe the inputs and outputs of the system. Information concerning how the inputs and outputs relate.

Nonbehavioral Requirements define the attributes of the system as it performs its job. They include a complete description of the system as it performs its job.

Importance of Requirements

Use

Use of Requirements

Data

1. The later in the life cycle that an error is detected the more expensive it is to repair.

2. Errors remain latent and are not detected until well after the stage at which they are made.

54% of errors detected after coding and unit testing.
45% of these errors were requirements and design errors.

3. There are numerous requirements errors.

Estimates indicate that 56% of all errors are errors during the requirements stage.

4. Requirements errors are typically nonclerical.

incorrect facts 49%
omissions 31%
inconsistencies 13%
ambiguities 5%

5. Requirements errors can be detected.

Review by Authors 23%
Review by Others 10%
As Design Reference 45%

Requirements Engineering

Costs

For large hardware/software systems about 15% of development budget.

For smaller systems which are mostly software around 10% of development budget.

Process

A structured set of activities which are followed to derive, validate and maintain a systems requirements document.

RE IDEF0 Model

Inputs

Existing System Information
Information about systems that either will be replaced by the proposed system, or which the system must interact with.
Stakeholder Needs
Descriptions of needs stakeholders perceived to have of the suggested system.
Domain Information
General information about the nature of the domain and the types of activities that are covered by the situation being considered.

Controls

Organizational Standards
Standards used in the organization to coordinate system development or maintain quality, etc.
Regulations
External regulations that need to be considered as the problem is considered and the solution evolves.

Mechanisms

Stakeholders
Are people or organizations affected by the system and who have a direct influence on the requirements
Analyst
The member of the project team responsible for managing the requirements process (requirements manager).

Outputs

Requirements
The agreed upon functional and non-functional requirements for the system.
System Specification
A more detailed version of the system which may be required in some instances.
System Models
Models, usually in diagrammatic form, which describe the system from the necessary perspectives.

Process Decomposition

RE Process Decomposition

Requirements Elicitation

Requirements elicitation is about understanding the "real" problem. This understanding comes from interacting with people that are intimately involved in a particular domain. Here is where the different stakeholders with their particular perspectives need to be identified. The problem solver needs to have the perspectives of all those involved in the current environment to make sense of their world.

Requirements Specification

The understanding of the problem is then cast in terms of a solution. This solution is referred to as the requirements specification. The problem solver takes the information collected during requirements elicitation and structures it in terms of a set of functional and non-functional requirements for the system.

Requirements V&V

The requirements that are written must be affirmed. There are two concerns: 1.are these the stated requirements correct? (validation)
2.are the requirements stated correctly? (verification)
It is important that the requirements engineering process not conclude until the requirements are agreed upon by the stakeholders.

Go To Lecture [Outline] [Overview]

Go To [311 Course Outline] [CIS Department Page]

References

Davis, A. (1995) Software Requirements. Englewood Cliffs, NJ: Prentice Hall.

Kotonya, G. & I. Sommerville (1998) Requirements Engineering. Chichester: John Wiley.