Module5-RequirementsAnalysisModelingEditedMar2021.pdf

Module 5: Requirements Analysis and Modeling Software Engineering School of Computing, Faculty of Engineering Universiti Teknologi Malaysia  Outline Part I: Requirements Modeling Concept – Use Case Modeling and Specification – Domain M...

Module 5: Requirements Analysis and Modeling Software Engineering School of Computing, Faculty of Engineering Universiti Teknologi Malaysia  Outline Part I: Requirements Modeling Concept – Use Case Modeling and Specification – Domain Modeling – Activity Diagram – Sequence Diagram – State Chart/State Machine Diagram Part II: Requirements Document – Software Requirements Specification (SRS) Note: The overall contents of the slide are based on the main reference that is Sommerville (2016) with other references specified directly in respective slides (if any) 2021 Software Engineering 2  Use Case Modeling and Specification, Sequence Diagram, Activity Diagram, Domain Modeling, State Chart/Machine Diagram PART I: REQUIREMENTS MODELING CONCEPT Note: Main reference for Part I: Sommerville (2016), Arlow and Neustadt (2002) 2021 Software Engineering 3  Objectives To define requirements using use cases and problem domain classes To identify and analyze events and resulting use cases for use case diagram To identify and analyze domain classes for domain model class diagram To produce detail requirements using sequence diagram, activity diagram and state chart/state machine diagram 2021 Software Engineering 4  System Modeling System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system System modeling represents a system using graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML) System modeling helps the analyst to understand the functionality of the system and models are used to communicate with customers 2021 Software Engineering 5  Existing and Planned System Models Models of the existing system are used during requirements engineering – They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses – These then lead to requirements for the new system Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders – Engineers use these models to discuss design proposals and to document the system for implementation 2021 Software Engineering 6  System Perspectives An external perspective: model the context or environment of the system An interaction perspective: model the interactions between a system and its environment, or between the components of a system A structural perspective: model the organization of a system or the structure of the data that is processed by the system A behavioral perspective: model the dynamic behavior of the system and how it responds to events 2021 Software Engineering 7  Context Model Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries Social and organisational concerns may affect the decision on where to position system boundaries Architectural models show the system and its relationship with other systems The context of Mentcare system 2021 Software Engineering 8  UML Diagram Types Activity diagrams show the activities involved in a process or in data processing Use case diagrams show the interactions between a system and its environment Sequence diagrams show interactions between actors and the system and between system components Class diagrams show the object classes in the system and the associations between these classes State diagrams show how the system reacts to internal and external events 2021 Software Engineering 9  Use of Graphical Models As a means of facilitating discussion about an existing or proposed system – Incomplete and incorrect models are fine at the early stage as their role is to support discussion As a way of documenting an existing system – Models should be an accurate representation of the system but need not be complete As a detailed system description that can be used to generate a system implementation – Models have to be both correct and complete 2021 Software Engineering 10  Ways of Writing a System Requirements Specification Recall Notation Description Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. Structured natural The requirements are written in natural language on a standard form or language template. Each field provides information about an aspect of the requirement. Design description This approach uses a language like a programming language, but with language more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications. Graphical notations Graphical models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used. Mathematical specifications These notations are based on mathematical concepts such as finite- state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract. 2021 Software Engineering 11  Use Case Diagram INTERACTION MODEL 2021 Software Engineering 12  Interaction Model Modeling user interaction is important as it helps to identify user requirements Modeling system-to-system interaction highlights the communication problems that may arise Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability Use case diagrams and sequence diagrams may be used for interaction modeling For the scope of this course, sequence diagrams will be discussed later under behavioural model 2021 Software Engineering 13  Use Case Modeling Use cases were developed originally to support requirements elicitation and now incorporated into the UML Each use case represents a discrete task that involves external interaction with a system Actors in a use case may be people or other systems Represented diagrammatically to provide an overview of the use case and in a more detailed textual form 2021 Software Engineering 14  Stereotypes in UML Stereotypes allow us to introduce new modeling elements based on existing elements Can do this by appending the stereotype name in guillemots («…») to the new element Each model element can have at most one stereotype Examples: 1. , in use case relationship 2. , , in class diagram as class stereotypes 3. , in package diagram 2021 Software Engineering 15  Use Case Diagram: Notation 2021 Software Engineering 16  Example: Use Case Diagram for Mentcare System Mentcare System Note: Use cases in the Mentcare system involving the role ‘Medical Receptionist’ 2021 Software Engineering 17  Use Case Description 2021 Software Engineering 18  Branching within a Flow and Alternative Flow 2021 Software Engineering 19 Repitition within a Flow: For/While 2021 Software Engineering 20  Relationship 2021 Software Engineering 21  Relationship 2021 Software Engineering 22  Example: Use Case Diagram for e-Commerce System 2021 Software Engineering 23  Example: Use Case Description for GoToCheckout Note: Extension points for relationship can be stated before preconditions in the use case description and in the flow of events where the extension occurs 2021 Software Engineering 24  Use Case Description for AcceptPaymentByCard and DisplayBasket 2021 Software Engineering 25  Class Diagram STRUCTURAL MODEL 2021 Software Engineering 26  Structural Models Structural models of software display the organization of a system in terms of the components that make up that system and their relationships Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing Create structural models of a system when discussing and designing the system architecture 2021 Software Engineering 27  Class Diagrams Class diagrams are used when developing an object- oriented system model to show the classes in a system and the associations between these classes An object class can be thought of as a general definition of one kind of system object An association is a link between classes that indicates that there is some relationship between these classes When developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc. 2021 Software Engineering 28 Domain Model Class Diagram Notation Class diagram key: – General class symbol: rectangle with three sections – Sections convey name, attributes, and behaviors – Methods (behaviors) not shown in domain model class diagram – Lines connecting rectangles show associations – Multiplicity reflected above connecting lines Domain class objects reflect business concern, policies, and constraints When moving to design, methods and details of methods are included (design class diagram) 2021 Software Engineering 29  Class and Object Instantiation 2021 Software Engineering 30  Class as a Template of Objects Note: Do not include operation part in analysis stage – only in design stage 2021 Software Engineering 31  Class Stereotype Syntax 2021 Software Engineering 32  Types of Class Stereotype Boundary class: interacts with actors outside the system and other objects in the system Entity class: a passive class i.e. does not initiate interactions on its own, store and manage information, normally persistent data Control class: coordinate boundary and entity object(s) – collect inform from boundary and dispatch to entity, usually has behavior specific for one use case Source: https://www.ibm.com/support/knowledgecenter/en/SS6RBX_11.4.2/com.ibm.sa.oomethod.doc/topics 2021 Software Engineering 33  Good Analysis Class What makes a good analysis class: its name reflects its intent it is a crisp abstraction that models one specific element of the problem domain it maps on to a clearly identifiable feature of the problem domain it has a small, well-defined set of responsibilities it has high cohesion it has low coupling Note: Our SE course focuses on domain models. Thus, the concepts of high cohesion and low coupling will be elaborated in design stage where we include operations in class diagram. 2021 Software Engineering 34  Association Note: The arrow head in navigability can be ignored in analysis stage OR 2021 Software Engineering 35  Multiplicity 2021 Software Engineering 36  Reflexive Association 2021 Software Engineering 37  Association Class 2021 Software Engineering 38  Generalization… Generalization is an everyday technique that can be used to manage complexity Rather than learning the detailed characteristics of every entity, place these entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of these classes This allows us to infer that different members of these classes have some common characteristics e.g. square, circle and triangle are shape 2021 Software Engineering 39  Generalization In modeling systems, it is often useful to examine the classes in a system to see if there is scope for generalization Do not have to look at all classes in the system to see if they are affected by the change in future In a generalization, the attributes and operations associated with higher-level classes are also associated with the lower-level classes The lower-level classes are subclasses inherit the attributes and operations from their superclasses These lower-level classes then add more specific attributes and operations 2021 Software Engineering 40  Class Generalization 2021 Software Engineering 41  Example: Generalization Hierarchy 2021 Software Engineering 42  Aggregation and Composition Note: The arrow head in navigability can be ignored in the analysis stage Part can exist without whole Part cannot exist without whole 2021 Software Engineering 43  Example: Classes and Associations in MHC-PMS 2021 Software Engineering 44  Example: Domain Model for Online Shopping Note: Stating the type for the attribute is optional in analysis stage source: https://www.uml-diagrams.org/index-examples.html 2021 Software Engineering 45  Activity Diagram, Sequence Diagram, State Diagram (State Chart/Machine) BEHAVIORAL MODEL 2021 Software Engineering 46  Behavioral Model Behavioral models are models of the dynamic behavior of a system as it is executing, show what happens or what is supposed to happen when a system responds to a stimulus from its environment Think of these stimuli as being of two types: – Data: Some data arrives that has to be processed by the system (activity diagram, sequence diagram) – Events: Some event happens that triggers system processing and may have associated data, although this is not always the case (state diagram) 2021 Software Engineering 47  Data-Driven Modeling Many business systems are data-processing systems that are primarily driven by data, controlled by the data input to the system, with relatively little external event processing Data-driven models show the sequence of actions involved in processing input data and generating an associated output They are particularly useful during the analysis of requirements as they can be used to show end- to-end processing in a system 2021 Software Engineering 48  Activity Diagram Activity diagrams are “OO flowcharts” that allow us to model a process as a collection of activities and transitions between those activities Activity diagrams are really just special cases of statecharts where every state has an entry action that specifies some process or function that occurs when the state is entered An activity diagram can be attached to any modeling element for the purpose of modeling the behavior of that element at different abstraction levels Activity diagrams are typically attached to: use cases, classes, interfaces, components, nodes, collaborations, operations and methods 2021 Software Engineering 49  Activity Diagram: Transition and Decision 2021 Software Engineering 50  Activity Diagram: Fork and Join 2021 Software Engineering 51  Activity Diagram: Swimlanes 2021 Software Engineering 52  Sequence Diagram Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects showing their behavior within a system A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance (scenario) The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these Interactions between objects are indicated by annotated arrows 2021 Software Engineering 53  Sequence Diagram Syntax Note: Related Use Case Description 2021 Software Engineering 54  Syntax/Notation Details Lifeline represents an individual participant (or object) in the interaction Focus of control (activation) specifies a behavior or interaction within the lifeline also known as execution specification Message defines a particular communication between lifelines of an interaction Examples of communication: raising a signal, invoking an operation, creating or destroying an instance 2021 Software Engineering 55  Types of Message Synchronous: – If a caller sends a synchronous message (in sequence), it must wait until the message is done before it proceeds with its business Asynchronous: – If a caller sends an asynchronous message, it can continue processing and does not have to wait for a response – Usually used in multithreaded applications and in message- oriented middleware Return message: – Return messages are an optional part of a sequence diagram – The use of return messages depends on the level of detail/abstraction that is being modeled – Return messages are useful if finer detail is required; otherwise, the invocation message is sufficient (Source: https://www.ibm.com/developerworks/rational/library/3101.html) 2021 Software Engineering 56  Message in Sequence Diagram To show an object (lifeline) sending a message to another object, draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). Besides message calls, there are return messages. These return messages are optional; a return message is drawn as a dotted line with an open arrowhead back to the originating lifeline, and above this dotted line you place the return value from the operation. Source: https://www.ibm.com/developerworks/rational/library/3101.html Source: Arlow and Neustadt (2002) 2021 Software Engineering 57  Iteration in Sequence Diagram guard 2021 Software Engineering 58  Branching and Self-Delegation 2021 Software Engineering 59  Concurrency: Active Objects asynchronous flow 2021 Software Engineering 60  Example: Sequence Diagram for View Patient Info in MHC-PMS alt: Alternative flow 2021 Software Engineering 61  Example: Sequence Diagram for Process Order argument Note: Sequence diagram also shows the interaction (interaction model) besides behaviour – in the analysis stage, the argument can be included (optional) 2021 Software Engineering 62  Example: Sequence Diagram Using Class Stereotypes Note: Sequence diagram with return messages (optional) using class stereotypes (optional) 2021 Software Engineering 63  Sequence Diagram: Scope for Analysis Each use case must have at least one sequence diagram that comprises normal flow and alternative flows – split only if it is cluttered to combine all Refer to use case description when creating a sequence diagram Focus on object interaction in domain model (class diagram for analysis) for a particular use case Not necessary to include boundary, controller and data layer that could be added in design stage 2021 Software Engineering 64  Event-Driven Modeling Some systems mainly real-time systems are often event-driven, with minimal data processing Examples: (Source: https://www.bbconsult.co.uk/blog/event-driven-applications) – A robot has reached its destination (real-time warehouse management) – An illegal trade pattern has been detected (fraud detection) – A loan application has been accepted/rejected (commercial business) Event-driven modeling shows how a system responds to external and internal events; is based on the assumption that a system has a finite number of states and the events (stimuli) may cause a transition from one state to another 2021 Software Engineering 65  State Chart or State Machine Diagram In OO approaches, state chart is drawn for a single class to show the lifetime behavior of a single object State chart is also known as state machine diagram State: a condition during the life of an object when it satisfies some conditions, performs some actions, or waits for an event – It is found by examining the attributes and links defined for the object – represented as a rectangle with rounded corners Transition: represents a change of the internal condition/state of an object 2021 Software Engineering 66  Event and State 2021 Software Engineering 67  State Syntax 2021 Software Engineering 68  State State: a semantically significant condition of an object Object state is determined by object attribute values, relationships to other objects, activities the object is performing State syntax: – entry action: performed immediately on entry to the state – exit action: performed immediately on exit from the state – internal transitions: these are caused by events that are not significant enough to warrant a transition to a new state, the event is processed by an internal transition within the state – internal activity: a piece of work that takes a finite amount of time and which may be interrupted 2021 Software Engineering 69  Identifying the Object Behavior In brief, a state in a state chart similar to status condition: – Spans many business events – Developed for complex problem domain classes State chart/state machine diagram – Composed of ovals representing status of object – Arrows represent transitions 2021 Software Engineering 70  Identify States Guidelines to help identify states: – Check naming convention for status conditions – Simple states reflect simple conditions such as “On” – Complex states labeled with gerunds or verb phrases Example: “Being shipped” – Active states usually not labeled with nouns – Describe only states of being of the object itself – Status conditions reported to management/customers Example: “Shipped” 2021 Software Engineering 71  Transition Transitions have a simple syntax that may be used for external transitions (shown by an arrow) or internal transitions (nested within a state). Every transition has three optional elements: – an event – this is an external or internal occurrence that triggers the transition – a guard condition – this is a Boolean expression that must evaluate to true before the transition can occur – an action – this is a piece of work associated with the transition, and occurs when the transition fires 2021 Software Engineering 72  Event UML defines an event as, “the specification of a noteworthy occurrence that has location in time and space.” Events trigger transitions in state machines Events may be shown externally on transitions There are four types of event, each of which has different semantics: 1. call event 2. signal event 3. change event 4. time event 2021 Software Engineering 73  Example: Call Event State Chart 2021 Software Engineering 74  Example: Signal Event State Chart Note: A state chart relates to the class that provides the signal e.g. OverdrawnAccount that triggers respective event and action 2021 Software Engineering 75 Example: Change Event State Chart 2021 Software Engineering 76  Example: Time Event State Chart 2021 Software Engineering 77  Example: State Diagram of a Microwave Oven 2021 Software Engineering 78  Example: Microwave Oven Operation 2021 Software Engineering 79  Rules for Developing State Charts 1. Select the classes that will require state charts 2. List all the status conditions for each group 3. Specify transitions that cause object to leave the identified state 4. Sequence state-transition combinations in correct order 5. Identify concurrent paths (if any) 6. Look for additional transitions 7. Expand each transition as appropriate 8. Review and test each state chart 2021 Software Engineering 80  Key Points… A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions, structure and behavior. Context models show how a system that is being modeled is positioned in an environment with other systems and processes. Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects. 2021 Software Engineering 81  Key Points Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations. Behavioral models are used to describe the dynamic behavior of an executing system. This behavior can be modeled from the perspective of the data processed by the system, or by the events that stimulate responses from a system. Activity diagrams may be used to model the processing of data, where each activity represents one process step. State diagrams are used to model a system’s behavior in response to internal or external events. 2021 Software Engineering 82  Software Requirements Specification (SRS) PART II: REQUIREMENTS DOCUMENT 2021 Software Engineering 83  Objective To understand how requirements may be organized in a software requirements document To adopt a standard in producing a requirements document To focus on specific requirements that include the analysis models 2021 Software Engineering 84  Software Requirements Document Software requirements document is an official statement of what is required for the reference of software developers Should include both definitions of user requirements and specifications of the system requirements It is NOT a design document As far as possible, it should set WHAT the system should do rather than HOW it should do it 2021 Software Engineering 85  User and System Requirements Recall 2021 Software Engineering 86  Users of a Requirements Document 2021 Software Engineering 87  Requirements Document Variability Information in requirements document depends on type of system and the approach used in its development Systems developed incrementally will, typically, have less detail in the requirements document Requirements documents standards have been designed e.g. IEEE standard These are mostly applicable to the requirements for large software projects 2021 Software Engineering 88  IEEE Std 830-1998 2021 Software Engineering 89  SRS Outline of IEEE Std 830-1998 See page 11 of IEEE Std 830-1998 2021 Software Engineering 90  Example of Template for the Front Part of SRS Document 2021 Software Engineering 91  Section 1: Introduction 2021 Software Engineering 92  Section 2: Overall Description, Sub-Section 2.1 2021 Software Engineering 93  Sub-sections 2.1.1 to 2.1.3 2021 Software Engineering 94  Sub-sections 2.2 & 2.3 2021 Software Engineering 95  Sub-sections 2.4 to 2.6 2021 Software Engineering 96  Section 3: Specific Requirements Note: Focus on “Specific Requirements” for the scope of this course – see the given System Documentation template that combines the required details for analysis (Section 2), design (Section 3 to 6) and testing (Section 7 and 8) to meet the minimum requirements of this course 2021 Software Engineering 97  Appendix A.5 Template of SRS Section 3: Organized by Feature (IEEE Std 830-1998) Sections 3.1.1 to 3.1.4 provide the details of what described in Sections 2.1.2 to 2.1.5 For each functional requirement, include the use case diagram and its details using use case description Include sequence diagram and activity diagram for each use case i.e. functional requirement Our Include state diagram for classes with states under Focus respective use cases 2021 Software Engineering 98  Key Points The software requirements document is an agreed statement of the system requirements It should be organized so that both system customers or users and software developers can use it Documentation standard can be referred and customized based on stakeholders’ needs 2021 Software Engineering 99