1. Organizing the Requirements Information 1

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

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

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

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

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

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

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

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

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

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

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

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

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