Organizing the Requirements Information

1

Need for Organizing Requirements Many stakeholders are involved in most

projects. They must reach agreement about the

system being built. Requirements must be organized so

they can be reviewed and approved. Traditionally, Requirements Specification

documents have been built to capture and communicate this information.

2

Problems with a Traditional Requirements Document The system may be very complex, and the

volume of documentation demands both organizational and interactive access techniques.

The system of interest may be a member of a family of related products. No one document can contain all the specifications.

The system being constructed may be a subsystem of a larger system and may satisfy only a subset of all requirements identified.

3

Problems with a Traditional Requirements Document (Cont’d)

Marketing and business goals need to be separated from the detailed product requirements.

Other requirements, perhaps regulatory or legal, may also be imposed on the system, and these requirements may be documented elsewhere.

4

Organizing Requirements of Complex H/W and S/W Systems

Complex systems can only be visualized and built as systems of subsystems

A system-level requirements set is created that describes the system with out reference to the subsystems.

Systems Engineering refines the system-level description into a system of subsystems.

The resulting system architecture describes this partitioning and the interfaces among the systems.

5

A System of Subsystems

The System

Subsystem A Subsystem B

Subsystem A-1 Subsystem A-2

Subsystem C

Subsystem C-1 Subsystem C-2

6

The Systems Engineering Process

After developing requirements for the system as a whole, requirements are developed for each subsystem.

The external behavior of each subsystem should be described completely without reference to any of its subsystems.

This process creates new classes of requirements, i.e., the interfaces among the subsystems become key requirements.

7

The Systems Engineering Process (Cont’d)

The process is repeated, breaking down each of the subsystems into subsystems and developing requirements for each.

The result is a hierarchy of requirements.

At every level requirements form the previous level are allocated to the appropriate lower-level system.

8

A Hierarchy of Requirements

Overall sytemRequirements

System requirementsfor Subsystem A

System requirementsfor Subsystem B

System requirementsfor Subsystem A-1

System requirementsfor Subsystem A-2

System requirementsfor Subsystem C

System requirementsfor Subsystem C-1

System requirementsfor Subsystem C-2

9

Organizing Requirements for Product Families

Companies often develop families of related products.

Much of the functionality may be common among products in the family.

Requirements can be organized based on the relationship between the products.

10

Approach for Organizing Requirements

Develop a product-family Vision document that describes the ways in which the products are intended to work together.

Develop a set of use cases showing how the users will interact with various applications running together.

11

Approach for Organizing Requirements (Cont’d)

Develop a common software requirements set that defines the specific requirements for shared functionality, e.g., menu structures, common GUIs, and communications protocols.

For each product in the family, develop a Vision document, supplementary specification, and a use-case model that defines its specific functionality.

12

“Future” Requirements

During the requirements elicitation process requirements may have been identified which are deemed appropriate for a subsequent release of the product.

On the one hand including these in the requirements set might cause confusion.

On the other hand we don’t want to forget about them.

13

“Future” Requirements (Cont’d)

Furthermore, system designers might design differently if they know about future requirements.

It’s probably best to record both present and future requirements but clearly identify which are planned for the current release and which are not.

14