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
Requirements Engineering These are the five activities involved in sw req engineering.
Software Requirements What vs How Dilemma3 User Needs What How System Requirements What How System Design What How Software Requirements What How Software Design
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
Component Development Software Requirements Systems Engineering System Test System Requirements System Requirements System Requirements System Architecture Component Development Integration Test Software Requirements Design Code Unit Test
System Engineering Issues Systems Engineering must address Functionality Usability Reliability Performance Scalability Capacity Supportability Maintainability Extensibility Portability Accurate communication to the implementation and test teams is critical for success.
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
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 …
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 “White box” -- glass box -- having to do with internals
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
Example of Use Case with System-Level Black Box
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 state diagrams use cases domain models system sequence diagram -- used it to mean top level of a program; now it means the top level of a system of programs
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
Impacts on Requirements Elicitation At the system level elicitation is done the same way At the component level elicitation is more about derived requirements
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
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 If independent QA group is responsible for system verification only, (that is, verification of system requirements), the developers are responsible for verifying the component requirements (largely as derived or implied requirements). What does it mean to be responsible for integration at the requirements level? verifying interfaces between components ensure that the integrated requirements of components combine to form the system level requirements
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