ACS2913 Software Requirements Analysis And Design PDF
Document Details
Uploaded by WinningZircon
The University of Winnipeg
2022
Tags
Summary
This document is a set of lecture notes on software requirements analysis and design (ACS2913) offered at the University of Winnipeg in Fall 2022. It covers topics including system sequence diagrams, use cases, and object-oriented analysis.
Full Transcript
ACS2913 Software Requirements Analysis and Design Instructor: David Tenjo EXTENDED REQUIREMENTS MODELING THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2022 1 System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages Overview CRUD analysis, which correlates proble...
ACS2913 Software Requirements Analysis and Design Instructor: David Tenjo EXTENDED REQUIREMENTS MODELING THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2022 1 System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages Overview CRUD analysis, which correlates problem domain classes and use cases, is an effective technique to double check that all required use cases have been identified Not all use cases are modelled at this level of detail. Only model when there is complexity and a need to communicate details Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 2 The Domain Model did not model how Use Cases interact with the system System Sequence Diagrams System Sequence Diagrams (SSD) model how interactions (incidents, events) unfold Domain Model used simplified Class Diagram(more on this later) SSDs use simplified Sequence Diagrams (More on this later) It's a type of UML (Unified Modeling Language) diagram used for this purpose. THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2017 3 1.Visual Representation: Provides a clear visual representation of how external actors (users or other systems) interact with a system. System Sequence Diagrams 2.Actors and System: Actors are entities external to the system. Actors are typically represented as stick figures, and the system is shown as a rectangle. Actors initiate actions that the system responds to. 3.Sequence of Actions: The SSD illustrates the sequence of actions between the actors and the system. Each action is shown as a labeled arrow, starting from the actor and pointing to the system, indicating the flow of control. 4.Use Cases: SSDs are used to depict specific use cases, showing the high-level steps an actor takes to achieve a goal using the system. The actions in the diagram represent the messages or method calls exchanged between the actor and the system. 5.Simplification: SSDs are typically simplified to focus on the essential interactions, leaving out low-level details. They provide an overview of the interaction without diving into the specifics of how the system performs each action. 6.Communication Clarity: SSDs help in clarifying communication between actors and the system, which is crucial for understanding system functionality and for later stages of software development, such as designing the system's behavior and user interfaces. 7.A Step Towards Requirements: SSDs can serve as a starting point for developing detailed system requirements. By visualizing how external actors interact with the system, they provide a foundation for designing the system's features and functionality. THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2023 4 System Sequence Diagram (SSD) Notation SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 5 SSD Message Examples with Loop Frame Used to represent iterations or loops within a sequence of actions SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 6 1.Repetition: A loop frame is typically drawn as an elongated rectangle with a "loop" label, encircling a sequence of actions. This indicates that the actions within the loop are repeated multiple times. Loop Frames 2.Condition: Loop frames often include a condition that specifies when the loop should continue or terminate. This condition can be expressed in simple terms, like "while X is true" or "until Y is achieved." 3.Sequential Flow: Actions within the loop frame are performed sequentially, just as they would be in a regular sequence diagram. The loop continues until the condition is met or the specified number of iterations is reached. 4.Clarity: Loop frames are used in SSDs to enhance clarity, especially when dealing with scenarios involving iterative processes or when certain actions need to be repeated based on specific criteria. THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2016 7 THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2017 8 [true/false condition] return-value := message-name (parameter-list) ◦ An asterisk (*) indicates repeating or looping of the message ◦ Brackets [ ] indicate a true/false condition. This is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message isn’t sent. ◦ Message-name is the description of the requested service written as a verb-noun. ◦ Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. ◦ Return-value on the same line as the message (requires :=) is used to describe data being returned from the destination object to the source object in response to the message. SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 9 Message Notation for SSD SSD Opt Frame (optional) Alt Frame (if-else) SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 10 1 2 3 4 / Identify input message • See use case flow of activities or activity diagram Describe the message using the message notation Identify any special conditions on input messages • Name it verb-noun: • Consider parameters the system will need • Iteration/loop frame • Opt or Alt frame Identify and add output return values • On message itself: aValue:= getValue(valueID) Steps for Developing SSD Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 11 SSD for Process Sale THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2016 12 SSD for Create customer account Use case SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 13 SSD for Ship items Use Case SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 14 SSDs are part of the Use Case analysis SSD ● Draw an SSD for a main success scenario of each use case, and frequent or complex alternative scenarios ● SSDs allow for black box description of the behavior of the system ● SSDs can also be used to illustrate collaborations between systems (or part of the systems) THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2017 15 Use Case Analysis CRUD TECHNIQUE THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2017 16 CRUD technique – Use Cases and CRUD • Create • Read/Report • Update • Delete A good cross-check against the existing set of use cases. Used in database context • Ensure that all classes have a complete “cover” of use cases Not for primary identification of use cases Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 17 Verifying use cases for Customer SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 18 Identify Identify all domain classes For each class verify that use cases exist to CRUD Analysis -Steps Verify Add • • • • Create a new instance Update existing instances Reads or reports on information in the class Deletes or archives inactive instances Add new use cases as required. Identify responsible stakeholders Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 19 Sample CRUD Matrix SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 20 Extending and Integrating Requirements Models THE UNIVERSITY OF WINNIPEG - ACS 2913 - FALL 2017 21 Use cases Extending and Integrating Requirements Models • Use case diagram • Use case description • Activity diagram • System sequence diagram (SSD) Domain Classes • Domain model class diagram • State machine diagram SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 22 Use Case Analysis Use case analysis is a process of collecting and describing the user requirements, - Actors and use cases. - The goal is to identify roles, processes, and classes within a software system. - It is usually used within the software development process. Use cases focus on the users of the system, not the system itself, thus the real system needs are brought to light early on. 23 Analysis based on Objects, which are things that users will be concerned with when using a system Aims to model functional requireme nts of the software while remaining completely independent from implementation Stages of OOA: Combines all behaviors, characteristics and states together into one analysis process • Find and define the objects. • Organize the objects. • Describe how the objects interact with one another. • Define the external behavior of the objects. • Define the internal behavior of the objects. ObjectOriented Analysis 24 Requirements Models SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 25 Integrating Requirements Models SYSTEMS ANALYSIS AND DESIGN IN A CHANGING WORLD, 7TH EDITION – CHAPTER 5 ©2016. CENGAGE LEARNING. ALL RIGHTS RESERVED. 26 System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages Summary CRUD analysis serves to verify that all domain classes are fully supported by the new system, i.e. have use cases to fully process all required actions Not all use cases and domain classes are modelled at a detailed level. Only model when there is complexity and a need to communicate details. All of the models must be consistent and integrate together to provide a complete picture of the requirements and specification. Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 27