Software (requirement) analysis using uml

Software Requirement Analysis using UML Software Requirement Analysis Using UMLAuthor: Dhiraj ShettyReviewer: Kedar TokekarCreation Date: March 16, 2009 -1-

Software Requirement Analysis using UMLIntroductionThe document hopes to break a common myth that software analysis is a non-logicalprocess. We attempt to present the entire process as a series of logical steps which couldbe followed to ensure customer satisfaction.This document is based on the knowledge base that has been collected from varioussources. Most of the steps followed here are based on the RUP model. -2-

Software Requirement Analysis using UMLWhat are Requirement Artifacts?Requirements artifacts are the diagrams/flowcharts/algorithms/documents that a softwaredesigner creates as a result of the process of developing and managing softwarerequirements. Each artifact serves a particular purpose for understanding andcommunicating either the user requirements or the software requirements. Each artifactprovides a view of the full set of requirements.The set of UML artifacts (not necessarily every type of UML diagram BUT only a subsetof UML diagram-types that the designer deems necessary) ensures that these views donot conflict with one another. The following figure illustrates the overall architecture ofthe requirements artifacts: Figure 1: Software Analysis ModelEach artifact in the above Software Analysis Model serves a particular purpose in finalgoal of capturing the system requirements:Use Case Model: The use case model consists of Actors, Use Case diagrams as well asUse Case specifications. Actors are entities external to the system which are unaffectedby the current design process (but interact with the system in clearly documented ways).The use-cases capture the high-level functionality of the system. The use casespecifications are the detailed description of how the actors interact with the system toachieve a specific goal. -3-

Software Requirement Analysis using UMLClass Diagrams: The Class Diagrams (analysis classes) show the entities that need towork together to ensure that our system realizes each use case specification. The ClassDiagrams contains the functional requirements of the software. Objects of each classfulfill their responsibilities in collaboration with objects of the other classes in the model.Sequence Diagrams: The Sequence Diagrams show how objects of classes in the ClassDiagram collaborate to realize a use case. Each use case specification is related to one ormore sequence diagramsActivity Diagrams: Activity diagrams are similar to flow charts. We use activitydiagrams for (visually) capturing the dynamic behavior of a given part of our system.State Diagrams: State transition diagrams can be used to describe the behavior of aclass, a use case, or a system. The key components of a state transition diagram are thestates, triggering events that cause a transition from one state to another or possibly backto the same state, guards on those transitions, and actions the entity can perform duringthe transitions.Software Requirements Specification (SRS): The SRS is the final (all-inclusive)artifact of the requirements development process. The SRS contains BOTH thespecification of the functional requirements for each class in the class diagram AND thenonfunctional requirements. The SRS may also contain a specification of the interfaces tothe system.We learn the entire process of software (requirement) analysis using an example. Webuild up the various artifacts starting from a simple problem statement given below:Problem Statement:Implement a Hotel Management System wherein the customer can book one of thefollowing kinds of rooms:SingleDoubleSuiteThe system takes care of the billing which includes the Room service/Std calls etc -4-

Software Requirement Analysis using UMLUse Case ModelThe use case model captures the interaction of the system with other external entities. Westart by enlisting a rough draft of the scenarios in which the system will be exercised andthen go on to refine the same (for capturing more specific details).The high-level overview of the system (given earlier) reveals the following use-casescenarios:1. Hotel Room reservation2. Room Service (Food)3. Telephone/Internet Service4. BillingWe now try to refine the above use-case scenarios for capturing more details. We try tomake good use of the available use-case relationships i.e. extends, includes andgeneralization (of both actors and use cases). Capturing such fine details helps in bothgetting a broader view of the system as well as encouraging reuse.Identifying the Actors & Elaborating the Use-case scenariosFrom the above identified use case scenarios we can deduce the following four broadcategories of actors 1. Customer 2. (Hotel) Employee 3. (Hotel) Manager (responsible for booking/tariff selection etc) 4. Hotel Register (Customer details/Billing details/Room availability details)Each of the above identified use case scenarios are then elaborated after takingcontinuous feedback from the customer. -5-

Software Requirement Analysis using UMLFigure 2: Actors of the Hotel Management System -6-

Software Requirement Analysis using UML Figure 3: Room Reservation Use Cases -7-

Software Requirement Analysis using UML Figure 4: Room Service Use Cases -8-

Software Requirement Analysis using UML Figure 5: Telephone Service Use Cases -9-

Software Requirement Analysis using UML Figure 6: Billing Use Cases - 10 -

Software Requirement Analysis using UML(Incrementally) Iterative development modelThis model is close to the iterative development model (as suggested by RUP). We firstsort the requirements (read as Use Cases) according to their: 1. Urgency (as decided by customer) 2. Complexity 3. Risk (as perceived by architect/developer)We then prioritize the use cases by taking a weighted average of the above 3 priorityvalues (weights could be decided after discussion with customer/client).For the Hotel Management system being considered here, we assume that the top 3 usecases (highest priority) are: 1. Make Reservation 2. Make Corporate Reservation 3. Make Group ReservationWe now do a complete iteration of software analysis for each of these 3 requirements.The other use cases are explored incrementally (in subsequent iterations).Use Case Name: Make ReservationAuthor (Date) of first Revision: Dhiraj Shetty (Feb 25th, 2009)Precondition: Hotel Register is updated with latest infoPost-condition: Hotel Register updated to include current bookingFailed Post-condition: Hotel Register remains unaffectedMain Flow:1. Customer gives itinerary (days of stay at hotel)2. System searches for room details3. System presents room types and tariffs4. Customer selects room and confirms tariff5. System records customer‟s name and address6. Manager confirms booking on system7. System generates confirmation receipt.Alternate Flow: Tariff Negotiation3.1. Customer asks for discount3.2. Manager does DSS analysis (external to system) to decide feasibility of discount Use Case Specification for “Make Reservation” - 11 -

Software Requirement Analysis using UMLUse Case Name: Make Corporate ReservationAuthor (Date) of first Revision: Dhiraj Shetty (Feb 25th, 2009)Precondition: Hotel Register is updated with latest infoPost-condition: Hotel Register updated to include current bookingFailed Post-condition: Hotel Register remains unaffectedMain Flow:1. Customer gives itinerary (days of stay at hotel)2. System searches for room details3. System presents room types and special corporate tariffs4. Customer selects room and confirms tariff5. System records the name and address of both the customer as well as guest (customer‟sclient/employee)6. Manager confirms booking on system7. System generates confirmation receipt.Alternate Flow: Tariff Negotiation3.1. Customer asks for discount3.2. Manager does DSS analysis (external to system) to decide feasibility of discount Use Case Specification for “Corporate Reservation”Use Case Name: Make Group ReservationAuthor (Date) of first Revision: Dhiraj Shetty (Feb 25th, 2009)Precondition: Hotel Register is updated with latest infoPost-condition: Hotel Register updated to include current bookingFailed Post-condition: Hotel Register remains unaffectedMain Flow:1. Customer gives itinerary (days of stay at hotel)2. System searches for room details3. System presents room types and special group tariffs4. Customer selects rooms and confirms tariff(s)5. System records name and address for each customer in group6. Manager confirms booking on system7. System generates confirmation receipt.Alternate Flow: Tariff Negotiation3.1. Customer asks for discount3.2. Manager does DSS analysis (external to system) to decide feasibility of discount Use Case Specification for “Group Reservation” - 12 -

Software Requirement Analysis using UMLIdentification of Analysis Classes:Analysis classes are categorized into the following 3 kinds: 1. Boundary Classes (the Interface)  Behavior that involves communication with an actor 2. Control Classes (the Use Case flow of events)  Behavior specific to a use case or part of a very important flow of events 3. Entity Classes(Persistent Data)  Behavior that involves the data encapsulated within the abstractionBoundary classes model the interaction between the system and its surroundings. As athumb rule we need one boundary class per „Actor‟-„Use Case‟ pair. They should bemodeled according to the type of boundary they represent. For e.g.:  Modeling a boundary with a human actor should stress more on how the interface will be presented to the user.  Modeling a boundary with an external system should stress more on the communication protocol.Control classes coordinate the activities of other objects that implement the functionalityof a use case. However they may share a many-to-many relationship with use cases. Thedesign of control cases should be independent of change in surroundings. They shouldalso be independent of the internal structure of their corresponding entity classes. It‟salways better to divide a given control class if: 1. Two different actors interact with the same control class in different ways 2. The control task performs more than one kind of task and each are equally susceptible to change during the life time of the system.Entity classes are used to hold and update information about an event, a person or somereal-life object. They are independent of the environment (the actors). Thus changing theGUI or communication protocol (for communicating with external entities) should entailchanging only the boundary classes, not the entity and control classes.Entity classes can be identified using the use case specifications. The first step in thisexercise is to identify all the nouns in the use case specification. These are the best hintsto the classes in the system. The verbs indicate the methods. The nouns which indicateentities external to the system (for e.g. Actors) are to be skipped. Entity classes may alsocome from the domain model (business entities). - 13 -

Software Requirement Analysis using UMLBoundary Classes identified are: 1. Manager-Reservation-behaviour 2. Customer-Reservation-behaviour 3. HotelRegister-Reservation-behaviourControl Classes identified are: 1. MakeReservation-Controller 2. GroupReservation-Controller 3. CorporateReservation-ControllerEntity Classes identified are: 1. Customer-info 2. Room-info 3. Reservation-info 4. Group-reservation-info 5. Corporate-reservation-infoDistribute Responsibilities between the Analysis ClassesResponsibilities of an object for a given Analysis class are characterized as: 1. The actions the object can perform 2. The knowledge that the object maintains and provides to other objectsAnalysis classes with only one responsibility are probably too simple, while those with adozen or more can potentially be split into several classes.Responsibilities are determined by drawing Sequence Diagrams OR CollaborationDiagrams for representing the use case flows. Collaboration diagrams do have a distinctadvantage over sequence diagrams in that they allow you to show more complexbranching as well as multiple concurrent flows of control. Sequence diagrams help in „topto bottom‟ chronological ordering of messages but only allow us to show simplebranching.We now draw interaction diagrams for every possible use case flow i.e. main flow and/oralternate flow and/or exception flow. The messages that are passed to the objects (ofAnalysis classes) automatically give us their responsibilities. Besides, some otherresponsibilities may also be derived from the non-functional requirements.While allocating responsibilities to entity classes it may be helpful to have a broaderoverview of the entire system (rather than just the current subset of use cases). For e.g.While designing the book reservation system for British Library (which has multiplebranches across India) it may be sensible for the BOOK entity to include methodsMOVE_LOCATION and GET_CURRENT_LOCATION. - 14 -

Software Requirement Analysis using UMLAnalysis of Responsibilities in Main flow of Make Reservation Use Case:Figure 7: Sequence Diagram for Make Reservation Behavior (Click on embedded image)The remaining part of this document will focus on the analysis of only the above use caseflow. In practice however we analyze all the flows (that have been selected for the currentiteration) in parallel. This ensures that we come up with a more comprehensive analysisfor the classes involved.The responsibilities of each analysis class are now identified using the incoming arrow toits corresponding lifeline (in the sequence diagram analysis). For example, we can list theresponsibility of customer-reservation-behavior class as: 1. Provide an UI to capture customer‟s itinerary dates. 2. Provide an UI to query room availability. 3. Provide an UI to display available rooms (arranged by category/rates). 4. Provide an UI to take room reservation confirmation. 5. Provide an UI to display reservation-confirmation details. 6. Provide an UI for capturing customer‟s personal data.Further the non-functional requirements may also affect the analysis either by: 1. Introducing new responsibilities OR 2. Affecting the descriptions of pre-identified responsibilities - 15 -

Software Requirement Analysis using UMLDefine AttributesAttributes are the information-holders of an analysis class. The name of the attributeshould clearly specify the information that the attribute holds. Optionally we could use ashort description for giving more details.Attributes are usually: 1. Simple data types like string/integer etc 2. Uniquely owned by the object (to which it belongs) i.e. no sharing across objects 3. Have no real behavior other than providing its value.It is always better to model a potential attribute as a separate analysis class in thefollowing conditions: 1. The information has a complex behavior. 2. The information is shared across objects OR 3. The information is passed “by reference” between two or more objects.For example, the attributes of the customer-info class could be defined as:  Integer Customer_ID  String Name  String Address  String Contact_NumberIncase the data types identified are advanced features/types provided by certain languages(like STL in C++) we should clearly document the expected behavior of the type. Thishelps to keep the requirements independent of the implementation mechanism. It alsoensures that we do not force any choices on the designer/developer.Establish Relationship between Analysis Classes (Class Diagrams)The analysis classes in this model don‟t represent actual classes to be implemented in thecode; instead they represent conceptual entities that interact to represent the behavior ofthe proposed software without thinking much about implementation issues likepersistence, performance or security. Besides, we do not apply any kind of designpatterns here. Design patterns like Strategy, Abstract Factory etc come into play duringthe next stage of converting the analysis to a formal design.We start with a quick overview of the kinds of class relationships:1. Association: A relationship between classes that allows instances of those classes tosend messages to each other. For example: An "Employee” works in a “Company".1a. Multiplicity: An example of this kind of association is many employees working atthe same company. In this case, the relation shows a star sign near the employee class.We can use UML to model „one to many‟, „many to many‟ and so forth kind of relations. - 16 -

Software Requirement Analysis using UML1b. Directed Association: Association between classes is considered to be bi-directionalby default. However we can fix the navigability of the association by using a directedassociation. The arrowhead identifies the container-contained relationship.1c. Reflexive Association: It does not need any special visual symbol. However, therelation will point back at the same class. An example of this kind of relation is when aclass has a variety of responsibilities. For example, an employee of a company can be amanager for another employee.2. Aggregation: When a class is formed as a collection of other classes, it is called anaggregation relationship between these classes. It is also called a "has a" relationship.2a. Composition: Composition is a special kind of aggregation relationship in which thelife-cycle of the contained object strictly ends at (or before) the destruction of thecontainer object.3. Inheritance/Generalization: Generalization is an "is a" relationship in which the childclass is a type of the parent class. Generalization is the basic mechanism for encouragingreuse. The child classes "inherit" the functionality defined in the parent class.4. Realization: In a realization relationship, one entity (normally referred to as aninterface) defines a set of functionalities as a contract and the other entity (normallyreferred to as a concrete class) "realizes" the contract by implementing the functionalitydefined in the contract.Class diagrams help in identifying relationships in the space domain. For example in thesystem currently under analysis, it may be helpful to capture that Group-reservation-infoand Corporate-reservation-info classes are inherited from Reservation-info class. - 17 -

Software Requirement Analysis using UMLNeed for Activity DiagramsActivity diagrams are used to model the dynamic behavior of any element of an objectoriented system. Two common uses include: 1. Modeling the flow of a use case 2. Modeling the behavior of an operation on a class(object)Modeling the use case flow is beneficial in cases in which the flow appears to be complexin terms of multiple alternate flows. It helps to get a broader picture of how the various(alternate) flows branch and merge at different points. Besides symbols like fork/joincould be intelligently used to capture information that may not be clear in the use casespecification. Activity diagrams can be a very helpful input in drawing the interactiondiagrams.Need for Interface Requirement SpecificationWhile designing systems that need to interface with (existing/pre-designed) externalsystems, we need to ensure that the external interfaces of our modules are compatiblewith the interfaces presented by the external system. The IRS is used to capture suchrequirements. Such interface requirements can also be represented on the class diagram(covered earlier) using the “Realization” relationship.For example, let us consider the scenario in which the Billing system needs to interfacewith an existing print server. In this case we document the interface provided by the printserver as follows:interface PrintServer {// defines an abstract printer server// requires: interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJobvoid initialize (Printer p);void print (Printer p, PrintDoc d);void displayPrintQueue (Printer p);void cancelPrintJob (Printer p, PrintDoc d);} //PrintServer Interface specification for Print ServerWe can then proceed to elaborate the interfaces for Printer and PrintDoc (if required).This ensures that the billing system developers know not only the procedural interfacebut also the data format to be followed for interfacing with the (existing) print server(s). - 18 -

Software Requirement Analysis using UMLNeed for State DiagramsState diagrams help us to capture certain requirements that may be very crucial to thecorrect/efficient working of the system. Even if they may not come directly into the finalSRS, they do affect the functional/non-functional requirements. A common example canbe that of a “Software Defect Tracking” system in which we need to capture not only thevalid states (like unassigned/assigned/resolved/deferred/retired) but also the valid statetransitions.Specifying Functional Requirements using the Class DiagramFunctional requirements are usually written in the language conducive to programmers.This means we are free to use standard programming constructs like sequence, iteration,conditional logic etc which may not necessarily be clear to the customer. We shouldinclude a short description of the need/responsibility of each class, each class-attribute aswell as each class-method.Specifying Non Functional RequirementsFunctional requirements specify the actions that the software must perform. Non-functional requirements place restrictions on the product being developed and/or thedevelopment process. They may also specify external constraints that the product mustmeet. Figure 8: Classification of Non Functional Requirements - 19 -

Software Requirement Analysis using UMLIt is usually difficult to identify non-functional requirements, unless clearly specified inthe problem statement. In such cases, it is better to probe the customer using open-endedquestions in each of the categories given in the above diagram.Software Requirement SpecificationThe SRS document is the official statement of what is required of the systemdevelopers. It is NOT a design document. To the extent possible, it should only specifyWHAT the system needs to do, rather than HOW it should do it.Each software product company/vendor usually has its own format for documenting therequirements. Ideally the SRS should include the following topics:  Introduction.  General system description.  Specific requirements.  Appendices.  Index. - 20 -

http://apeia.eu	9
http://www.linkedin.com	3
http://localhost:65464	2
http://www.slideshare.net	1

Software (requirement) analysis using uml

by Dhiraj Shetty

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 15

Statistics