Requirements for Multi-Program Systems

Slides:



Advertisements
Similar presentations
1 Aspects of IEEE P1471 Viewpoints in Unified Modeling Language (UML) Manzur Ashraf, BRAC University Humayra Binte Ali, Dhaka University Md.Mahfuz Ashraf,
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Communication Notation Part V Chapter 15, 16, 18 and 19.
Requirements Analysis & Requirements Specification Originally developed by Michael Madigan StorageTek Manager, PAL Engineering Software Engineering of.
SE 555 Software Requirements & Specification Requirements Management.
Introduction to Software Architecture. What is Software Architecture?  It is the body of methods and techniques that help us to manage the complexities.
Requirements Analysis Concepts & Principles
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
SE 555 – Software Requirements & Specifications Introduction
1 REQUIREMENTS ENGINEERING and SYSTEMS ANALYSIS Elements and Definitions.
Package design and the Iterative process model. What is a package? Classes are not sufficient to group code –Some classes collaborate, implying dependencies.
Course Instructor: Aisha Azeem
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Unified Modeling Language
Object-Oriented Analysis and Design
Effective Methods for Software and Systems Integration
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Introduction to Software Engineering CEN 4010.
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
CompSci 230 Software Design and Construction
Copyright by Dr. Clarence Lau, IVE(TY)
CPIS 357 Software Quality & Testing
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
ArchiMate Authors : eSchoolink Group - ITNLU. Contents 1. What’s ArchiMate ? 2. Why ArchiMate ? 3. Main Benefits of ArchiMate 4. Layers of ArchiMate 5.
Software Design: An Introduction by David Budgen Presented by Shane Marcus EEL 6883 – Spring 2007 Presented by Shane Marcus EEL 6883 – Spring 2007.
Software Requirements Engineering CSE 305 Lecture-2.
From Use Cases to Test Cases 1. A Tester’s Perspective  Without use cases testers will approach the system to be tested as a “black box”. “What, exactly,
Software Reviews & testing Software Reviews & testing An Overview.
OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN. COURSE OUTLINE The world of the Information Systems Analyst Approaches to System Development The Analyst as.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
1 UML Basic Training. UML Basic training2 Agenda  Definitions: requirements, design  Basics of Unified Modeling Language 1.4  SysML.
Question To know that quality has improved, it would be helpful to be able to measure quality. How can we measure quality?
Lecture 7: Requirements Engineering
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 05. Review Software design methods Design Paradigms Typical Design Trade-offs.
ניתוח מערכות מידע 1 Unified Modeling Language (UML) § § The Unified Modeling Language (UML) is the industry-standard language for: Specifying, Visualizing,
TESTING LEVELS Unit Testing Integration Testing System Testing Acceptance Testing.
Software Engineering COSC 4460 Class 4 Cherry Owen.
Managing Change 1. Why Do Requirements Change?  External Factors – those change agents over which the project team has little or no control.  Internal.
Chapter 7 The Object-Oriented Approach to Requirements.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
ANKITHA CHOWDARY GARAPATI
Formal Methods.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
310414IMPLEMENTATION1 IMPLEMENTATIONIMPLEMENTATION SOFTWARE ENGINEERING SOFTWARE ENGINEERING.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
4+1 View Model of Software Architecture
Software Engineering Lecture 10: System Engineering.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Requirements. Outline Definition Requirements Process Requirements Documentation Next Steps 1.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Software Design and Development Development Methodoligies Computing Science.
 System Requirement Specification and System Planning.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Software Engineering (CSI 321)
How Systems are Developed
SysML v2 Usability Working Session
Software Requirements
EIN 6133 Enterprise Engineering
Introduction to Software Testing
Lecture 06:Software Maintenance
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Rapid software development
UML Design for an Automated Registration System
Presentation transcript:

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