1. Requirements for Multi-Program Systems Software Engineering of Multi-program Systems University of Colorado, Boulder Originally developed by Michael Madigan, StorageTek March, 2002 Minor revisions, September, 2002, by R. Dameron

2. Requirements Engineering

3. What vs How Dilemma3 User Needs WhatHow System Requirements WhatHow System Design WhatHow SoftwareRequirements WhatHow SoftwareDesign

4. What are the issues for multi-program requirements • What do you put in your SRS requirements for multi-program systems? • Legacy systems linked together • Different reliability for system components • Performance requirements • What about a system requirements specification? • System Requirements defines system “whats” • System reliability/availability • System performance • System Architecture defines components based on system requirements

5. Systems Engineering SystemTest System Requirements System Requirements System Requirements System Architecture ComponentDevelopment IntegrationTest Software Requirements Design Code Unit Test

6. System Engineering Issues • Systems Engineering must address • Capacity • Supportability • Maintainability • Extensibility • Portability • Functionality • Usability • Reliability • Performance • Scalability • Accurate communication to the implementation and test teams is critical for success.

7. Legacy Systems • If software based, legacy system behavior goes into Software Requirement Specification • External Interfaces • How legacy software behaves • Can be a reference to user manual or existing software documentation, if it exists • What the new behavior needs to be • If hardware and software based, legacy system behavior goes into System Requirements Specification

8. Derived Requirements • A requirement for a lower level (e.g. subsystem) discovered by analysis of the upper level requirement • New requirement, not an allocated system requirement • Derivation is based on studying how viewpoint elements collaborate to carry out system requirements • Same form at all levels • Use Cases • Supplementary Requirements • Can apply technique at various levels • Enterprise to system • System to subsystem • Subsystem to …

9. Derived requirements from system requirements specification • Use Cases for functional requirements • System components are actors along with the external actors • While the system requirements are black box, the derived requirements are white box. • Each program/component has its own Software Requirements Specification • Each program/component can be developed using different environments, teams, languages • With extremely careful attention paid to interfaces

10. Impact on Requirements Analysis • The farther you flow down to more detailed layers of abstraction, the what and how move accordingly • Other system components become actors as you flow down • Black box Use Cases are still critical and initiate the component Use Cases

11. Example of Use Case with System-Level Black Box

12. Requirements Specification Notations • Consider examples of requirements notations • Discuss how/whether the notation needs to change at system level • state diagram • what constitutes a represented event? • what causes a state transition? • difference between circles that are states and circles that are components • is it always the case that an event causing a transition to another component is necessarily a state change?? • domain models • system sequence diagrams • use cases

13. Impact on Requirements Specification • Specifications as they flow down may be owned by several groups • Specifications as they flow down may be in different forms and tools • Traceability must still occur up to your highest level requirements document

14. Impacts on Requirements Elicitation • At the system level elicitation is done the same way • At the component level elicitation is more about derived requirements

15. Impacts on Requirements Management • How the requirements are baselined is affected • As you flow down, change control procedures can be looser as long as interfaces to different components are tightly controlled. • Traceability must be maintained • May be more distributed

16. Impacts on Requirements Verification • This varies depending on the Verification strategy • QA dept. responsible for system verification means • Developers are responsible for the components. • Developers are responsible for integration. • This works for smaller systems and teams • QA dept. responsible for system and component verification • QA or Configuration Management also responsible for integration. • This works for larger teams but tends not to work for smaller teams. • Can tend to be more bureaucratic. • Verification technique • Determine sets of test values for selected use cases • Walkthrough use cases using selected diagrams • Note adequate completeness of diagrams vis a vis the use cases

17. References • 1 “Requirements Analysis,” Richard Thayer, SMC 10/97 Version 2, 1997 • 2 “IEEE Guide for Software Requirements Specification,” IEEE 830-1984 • 3 “Software Requirements:Objects, Functions, and States”, Prentice Hall, 1993 • 4 Software Quality Measurement for Distributed Systems, RADC-TR-83-175