Organizing the Requirements Information

1. Organizing the Requirements Information

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

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

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

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

6. A System of Subsystems The System Subsystem A Subsystem B Subsystem C Subsystem A-1 Subsystem A-2 Subsystem C-1 Subsystem C-2

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

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

9. A Hierarchy of Requirements Overall sytem Requirements System requirements for Subsystem A System requirements for Subsystem B System requirements for Subsystem C System requirements for Subsystem A-1 System requirements for Subsystem A-2 System requirements for Subsystem C-1 System requirements for Subsystem C-2

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

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

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

13. “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.

14. “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.