Software Requirements Menouer Boubekeur, Gregory Provan
Lectures Introduction to UML Introduction to Requirements Analysis Advanced techniques for Requirement Analysis M. Boubekeur, CSL, University College Cork page 2-2 -
Objectives To introduce techniques for requirements elicitation and analysis To describe functional and non-functional requirements To explain how software requirements may be organised in a requirements document To learn how to write requirement M. Boubekeur, CSL, University College Cork page 3-3 -
Lectures Introduction to UML Introduction to Requirements Analysis Advanced techniques for Requirement Analysis M. Boubekeur, CSL, University College Cork page 4-4 -
Software Process Models Waterfall process Requirement Design Implementation Verification Maintenance 5 M. Boubekeur, CSL, University College Cork - 5 -
Software Process Models Iterative process Initial Planning Requirement Planning Analysis and Design Evaluation Implementatio n Testing 6 M. Boubekeur, CSL, University College Cork - 6 -
Incremental Development Requirement Analysis phases Preliminary Design Design Design Design Code & UT Code & UT Code & UT Integration Test Partial code testing Partial code testing Integration Test Integration Test modules Qualification Test M. Boubekeur, CSL, University College Cork - 7 -
What is modeling? Modeling consists of building an abstraction of reality. Abstractions are simplifications because: They ignore irrelevant details and They only represent the relevant details. What is relevant or irrelevant depends on the purpose of the model. M. Boubekeur, CSL, University College Cork - 8 -
Systems, Models and Views A model is an abstraction describing a subset of a system A view depicts selected aspects of a model A notation is a set of graphical or textual rules for depicting views Views and models of a single system may overlap each other Examples: System: Aircraft Models: A flight simulation model Views: All blueprints, electrical wiring, fuel system M. Boubekeur, CSL, University College Cork - 9 -
Modeling with UML This lecture describes modeling concepts. A special focus is on object-oriented modeling. The notation of the Unified Modeling Language is introduced. The major elements of UML are explained. The basic semantics are described and illustrated on examples. M. Boubekeur, CSL, University College Cork - 10 -
Modeling with UML: Intro (1) UML (Unified Modeling Language) An emerging standard for modeling object-oriented software. Resulted from the convergence of notations from three leading object-oriented methods: OMT (James Rumbaugh) OOSE (Ivar Jacobson) Booch (Grady Booch) Reference: Dan Pilone, Neil Pitman. UML 2.0 in a nutshell, O Reilly 2005. Supported by several CASE tools Rational ROSE TogetherJ ARGOUML M. Boubekeur, CSL, University College Cork - 11 -
Modelling with UML: Intro (2) Notations enable engineers to articulate complex ideas succinctly and precisely. Accuracy and clarity are critical. The cost of miscommunication increases rapidly in projects involving many participants (often of different technical and cultural backgrounds). When a notation is used by a large number of participants, there is little room for misinterpretation and ambiguity. To enable accurate communication, a notation must come with a well-defined semantics, must be well suited for representing a given aspect of a system, and must be well understood among project participants. M. Boubekeur, CSL, University College Cork - 12 -
Modeling with UML: Intro (3) UML is a language There are rules about how elements are put together. Current release is UML 2.0 Common uses of UML include: Designing Software. Communicating Software or business processes. Capturing details about a system for requirements or analysis. Documenting an existing system, process, or organisation. UML is a set of specifications from the Object Management Group www.omg.org M. Boubekeur, CSL, University College Cork page 13-13 -
Modeling with UML: Intro (4) Main building block in UML is the diagram For software design, UML bridges the gap between the original idea and its implementation Collaboration Diagrams capture what parts of the software realise certain requirements Sequence and Statechart diagrams capture how exactly parts of a software systems realise their requirements Component and deployment diagrams show how all components fit together M. Boubekeur, CSL, University College Cork - 14 -
Modeling with UML: Intro (5) UML 2.0 divides diagrams into two categories Structural diagrams captures the physical organisation of things in the system. Behavioural diagrams capture the behaviour of elements in a system. Views While not part of UML the concept of systems views is supported. Models are often divided into 4+1 views of a system four distinct views of a system and one overview of how everything fits together. M. Boubekeur, CSL, University College Cork - 15 -
4+1 View Model Design View Implementation View Use Case View Process View Deployment View M. Boubekeur, CSL, University College Cork - 16 -
Structural diagrams UML 2.0 structural diagrams consist of the following models: CLASS DIAGRAMs describe the structure of a system in terms of objects, attributes, associations, and operations. they represent the object model of the system. COMPONENT DIAGRAMs describe the organisation and dependencies involved in the implementation. smaller elements, such as classes, can be grouped into larger deployable pieces. COMPOSITE STRUCTURE DIAGRAMs link class diagrams and component diagrams. show how elements in a system combine to realise patterns. DEPLOYMENT DIAGRAMs describes how the system is actually executed and deployed. PACKAGE DIAGRAMs describes how classes and interfaces are grouped together. OBJECT DIAGRAMs describe how instances of classes are related at a specific instance of time. M. Boubekeur, CSL, University College Cork page 17-17 -
Behavioural diagrams UML 2.0 behavioural diagrams consist of the following models: ACTIVITY DIAGRAMS describe the flow from one behaviour or activity to the next. COMMUNICATION DIAGRAMs describe the objects involved in a particular behaviour and what messages are passed between the objects. INTERACTION OVERVIEW DIAGRAMs describe what object has the focus of control throughout the execution. SEQUENCE DIAGRAMs describe the type and order of messages exchanged among a set of objects. STATE CHART(MACHINE) DIAGRAMs describe behaviour in terms of states of an individual object and the possible transitions between states. TIMING DIAGRAMs describe detailed timing specifications for messages between objects. USE CASE DIAGRAMs describe the functional requirements of a system. M. Boubekeur, CSL, University College Cork - 18 -
Classifiers and Adornments The basic modelling element in UML is the classifier which represents a group of things with common properties. Classes with common properties such as methods, attributes, exceptions, visibility. A classifier general notation is a rectangle. A classifier may have extra types of information attached called adornments. Restrictions places on values certain features of a classifier can take. M. Boubekeur, CSL, University College Cork - 19 -
Rules Nearly everything in UML is optional. Show only that helps to clarify the designed system that makes sense to you, the developer, and your audience. UML models are rarely complete. Depending on system complexity it is easy to leave information out of a UML model. It is information to support all key components of the design that have an impact on the overall system. UML is designed to be open to interpretation. Important to develop an in-house UML use standard to avoid design confusion and improve design clarity among developers working on the same team. UML is intended to be extended. UML includes several mechanisms to allow customisation and refinement of the language adornments, stereotypes, constraints. M. Boubekeur, CSL, University College Cork - 20 -
Main UML Components The five main components in UML: Use case diagrams Class diagrams Sequence diagrams Statechart diagrams Activity diagrams M. Boubekeur, CSL, University College Cork page 21-21 -
UML Core Conventions Rectangles are classes or instances Ovals are functions or use cases Instances are denoted with an underlined names mywatch:simplewatch Joe:Firefighter Types are denoted with non underlined names SimpleWatch Firefighter Diagrams are graphs Nodes are entities Arcs are relationships between entities M. Boubekeur, CSL, University College Cork - 22 -
USE CASEs USE CASES: are used during requirements elicitation and analysis to represent the functionality of the system. focus on the behaviour of the system from an external point of view. describe a function provided by the system that yields a visible result for an actor. AN ACTOR: describes any entity that interacts with the system (e.g. a user, another system, the system s physical environment). The identification of actors and use cases results in the DEFINITION of the BOUNDARY of the system. M. Boubekeur, CSL, University College Cork page 23-23 -
Use case diagrams System Boundary Watch Use case Actor ReadTime WatchUser SetTime WatchRepairPerson ChangeBattery Use case diagrams represent the functionality of the system from user s point of view M. Boubekeur, CSL, University College Cork - 24 -
Use Case Diagrams Used during requirements elicitation to represent external behavior Passenger PurchaseTicket Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment
Actors Passenger An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates
Use Case PurchaseTicket A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements
System Boundary TicketSystem Passenger PurchaseTicket USE CASES capture the functionality of a particular subject. Anything not realised by the subject is considered outside the system boundaries and should be modelled as an actor. System Boundaries are represented using a rectangle with the name of the system on top.
System Boundary Maintenance Management System Reports a fault Plans regular maintenance Occupant Monitors maintenance Facilities Manager Logs a fault BMS / Network Fault detection Requests schedule Engineer
A Template to Describe Use Cases Name Participating actors Entry conditions Flow of events Exit conditions Quality requirements Written in natural language
A Use Case Example Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Exit condition: Passenger has ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket.
Use Case and Scenario A use case is an abstract that describes all possible scenarios involving the described functionality A scenario is an instance of a use case describing a concrete set of actions. The focus of a scenario is on understandability The focus on a use case is on completeness
Use Case and Scenario Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Exit condition: Passenger has ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. On July 28th, 2009, Caitriona standed in front of a ticket distributor in Cork Train station. Anything missing? Exceptional cases!
The <<extends>> Relationship Ability to add additional functionality to a base use case if specified conditions are met. Passenger PurchaseTicket This extension relationship is indicated using a dashed dependency line with an open arrow, labelled with the keyword extend. Further detail can be supported using extension points and a note attached to the dependency line. <<extends>> OutOfOrder <<extends>> <<extends>> <<extends>> TimeOut Cancel NoChange
The <<includes>> Relationship Passenger PurchaseMultiCard PurchaseSingleTicket <<includes>> <<includes>> CollectMoney <<extends>> <<extends>> NoChange Cancel Common functionality from several use cases can be factored out that including a shared use case. Use case inclusion uses a dashed line with an open arrow pointing from the base use case to the included use case. The line is labelled with the keyword include.
Use Cases: Examples SimpleWatch ReadTime WatchUser SetTime ChangeBattery WatchRepairPerson page 36
Use Cases: Examples IT System Database Administrator Replicate Databases Backup User Data Startup Backup Administrator Shutdown Deploy Web Application Deployment Administrator M. Boubekeur, CSL, University College Cork page 37-37 -
Use Cases: Examples IT System System Administrator Startup Shutdown Database Administrator Replicate Databases Backup Administrator Backup User Data Deploy Web Application Deployment Administrator M. Boubekeur, CSL, University College Cork - 38 -
Use Cases: Examples Building Performance Analysis & Diagnosis Designer Develops the Performance Framework Automated Maintenance Building Operator Monitors Building Performance Requests environment changes Facilities Manager Occupant M. Boubekeur, CSL, University College Cork - 39 -
Resume: From uses case to code Building Performance Analysis & Diagnosis Designer Develops the Performance Framework Automated Maintenance Building Operator Monitors Building Performance Requests environment changes Facilities Manager Occupant Specified by Realised by Deployed by Analysis Model Implemented by Conception Model Verified by Deployment Model Implementation Model Test Model M. Boubekeur, CSL, University College Cork - 40 -
Use Case Diagrams: Summary Use case diagrams represent external behavior Use case diagrams are useful as an index into the use cases Use case descriptions provide meat of model. All use cases need to be described for the model to be useful. An Actor is a role of an object or objects outside of a system that interacts directly with it as part of a coherent work unit (a use case) <<includes>> and <<extends>> allow common fragments of use cases to be pulled out into a separate use cases <<includes>> is like a use case subroutine <extends>> is an alternative course of action Generalization M. Boubekeur, CSL, University College Cork - 41 -
g{tç~á Menouer Boubekeur, Gregory Provan menouer.boubekeur@gmail.com Cork Complex Systems Lab.