Software (requirement) analysis using uml

Software Requirement Analysis using UML

Software Requirement Analysis
Using UML

-1-


Introduction
The document hopes to break a common myth that software analysis is a non-logical
process. We attempt to present the entire process as a series of logical steps which could
be followed to ensure customer satisfaction.

This document is based on the knowledge base that has been collected from various
sources. Most of the steps followed here are based on the RUP model.

-2-


What are Requirement Artifacts?

Requirements artifacts are the diagrams/flowcharts/algorithms/documents that a software
designer creates as a result of the process of developing and managing software
requirements. Each artifact serves a particular purpose for understanding and
communicating either the user requirements or the software requirements. Each artifact
provides a view of the full set of requirements.

The set of UML artifacts (not necessarily every type of UML diagram BUT only a subset
of UML diagram-types that the designer deems necessary) ensures that these views do
not conflict with one another. The following figure illustrates the overall architecture of
the requirements artifacts:

Figure 1: Software Analysis Model

Each artifact in the above Software Analysis Model serves a particular purpose in final
goal of capturing the system requirements:

Use Case Model: The use case model consists of Actors, Use Case diagrams as well as
Use Case specifications. Actors are entities external to the system which are unaffected
by 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 case
specifications are the detailed description of how the actors interact with the system to
achieve a specific goal.

-3-


Class Diagrams: The Class Diagrams (analysis classes) show the entities that need to
work together to ensure that our system realizes each use case specification. The Class
Diagrams contains the functional requirements of the software. Objects of each class
fulfill 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 Class
Diagram collaborate to realize a use case. Each use case specification is related to one or
more sequence diagrams

Activity Diagrams: Activity diagrams are similar to flow charts. We use activity
diagrams 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 a
class, a use case, or a system. The key components of a state transition diagram are the
states, triggering events that cause a transition from one state to another or possibly back
to the same state, guards on those transitions, and actions the entity can perform during
the transitions.

Software Requirements Specification (SRS): The SRS is the final (all-inclusive)
artifact of the requirements development process. The SRS contains BOTH the
specification of the functional requirements for each class in the class diagram AND the
nonfunctional requirements. The SRS may also contain a specification of the interfaces to
the system.

We learn the entire process of software (requirement) analysis using an example. We
build 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 the
following kinds of rooms:
Single
Double
Suite

The system takes care of the billing which includes the Room service/Std calls etc

-4-


Use Case Model
The use case model captures the interaction of the system with other external entities. We
start by enlisting a rough draft of the scenarios in which the system will be exercised and
then go on to refine the same (for capturing more specific details).

The high-level overview of the system (given earlier) reveals the following use-case
scenarios:
1. Hotel Room reservation
2. Room Service (Food)
3. Telephone/Internet Service
4. Billing

We now try to refine the above use-case scenarios for capturing more details. We try to
make good use of the available use-case relationships i.e. extends, includes and
generalization (of both actors and use cases). Capturing such fine details helps in both
getting a broader view of the system as well as encouraging reuse.

Identifying the Actors & Elaborating the Use-case scenarios

From the above identified use case scenarios we can deduce the following four broad
categories 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 taking
continuous feedback from the customer.

-5-


Figure 2: Actors of the Hotel Management System

-6-


Figure 3: Room Reservation Use Cases

-7-


Figure 4: Room Service Use Cases

-8-


Figure 5: Telephone Service Use Cases

-9-


Figure 6: Billing Use Cases

- 10 -


(Incrementally) Iterative development model
This model is close to the iterative development model (as suggested by RUP). We first
sort 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 priority
values (weights could be decided after discussion with customer/client).

For the Hotel Management system being considered here, we assume that the top 3 use
cases (highest priority) are:
1. Make Reservation
2. Make Corporate Reservation
3. Make Group Reservation

We 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 Reservation
Author (Date) of first Revision: Dhiraj Shetty (Feb 25th, 2009)
Precondition: Hotel Register is updated with latest info
Post-condition: Hotel Register updated to include current booking
Failed Post-condition: Hotel Register remains unaffected

Main Flow:

1. Customer gives itinerary (days of stay at hotel)
2. System searches for room details
3. System presents room types and tariffs
4. Customer selects room and confirms tariff
5. System records customer‟s name and address
6. Manager confirms booking on system
7. System generates confirmation receipt.

Alternate Flow: Tariff Negotiation
3.1. Customer asks for discount
3.2. Manager does DSS analysis (external to system) to decide feasibility of discount

Use Case Specification for “Make Reservation”

- 11 -


Use Case Name: Make Corporate Reservation

Main Flow:

3. System presents room types and special corporate tariffs
4. Customer selects room and confirms tariff
5. System records the name and address of both the customer as well as guest (customer‟s
client/employee)


Use Case Specification for “Corporate Reservation”

Use Case Name: Make Group Reservation

Main Flow:

3. System presents room types and special group tariffs
4. Customer selects rooms and confirms tariff(s)
5. System records name and address for each customer in group


Use Case Specification for “Group Reservation”

- 12 -


Identification 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 abstraction

Boundary classes model the interaction between the system and its surroundings. As a
thumb rule we need one boundary class per „Actor‟-„Use Case‟ pair. They should be
modeled 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 functionality
of a use case. However they may share a many-to-many relationship with use cases. The
design of control cases should be independent of change in surroundings. They should
also be independent of the internal structure of their corresponding entity classes. It‟s
always 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 some
real-life object. They are independent of the environment (the actors). Thus changing the
GUI or communication protocol (for communicating with external entities) should entail
changing only the boundary classes, not the entity and control classes.

Entity classes can be identified using the use case specifications. The first step in this
exercise is to identify all the nouns in the use case specification. These are the best hints
to the classes in the system. The verbs indicate the methods. The nouns which indicate
entities external to the system (for e.g. Actors) are to be skipped. Entity classes may also
come from the domain model (business entities).

- 13 -


Boundary Classes identified are:
1. Manager-Reservation-behaviour
2. Customer-Reservation-behaviour
3. HotelRegister-Reservation-behaviour

Control Classes identified are:
1. MakeReservation-Controller
2. GroupReservation-Controller
3. CorporateReservation-Controller

Entity Classes identified are:
1. Customer-info
2. Room-info
3. Reservation-info
4. Group-reservation-info
5. Corporate-reservation-info

Distribute Responsibilities between the Analysis Classes
Responsibilities 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 objects

Analysis classes with only one responsibility are probably too simple, while those with a
dozen or more can potentially be split into several classes.

Responsibilities are determined by drawing Sequence Diagrams OR Collaboration
Diagrams for representing the use case flows. Collaboration diagrams do have a distinct
advantage over sequence diagrams in that they allow you to show more complex
branching as well as multiple concurrent flows of control. Sequence diagrams help in „top
to bottom‟ chronological ordering of messages but only allow us to show simple
branching.

We now draw interaction diagrams for every possible use case flow i.e. main flow and/or
alternate flow and/or exception flow. The messages that are passed to the objects (of
Analysis classes) automatically give us their responsibilities. Besides, some other
responsibilities may also be derived from the non-functional requirements.

While allocating responsibilities to entity classes it may be helpful to have a broader
overview 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 multiple
branches across India) it may be sensible for the BOOK entity to include methods
MOVE_LOCATION and GET_CURRENT_LOCATION.

- 14 -


The remaining part of this document will focus on the analysis of only the above use case
flow. In practice however we analyze all the flows (that have been selected for the current
iteration) in parallel. This ensures that we come up with a more comprehensive analysis
for the classes involved.

The responsibilities of each analysis class are now identified using the incoming arrow to
its corresponding lifeline (in the sequence diagram analysis). For example, we can list the
responsibility 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 -


Define Attributes
Attributes are the information-holders of an analysis class. The name of the attribute
should clearly specify the information that the attribute holds. Optionally we could use a
short 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 the
following 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_Number

Incase 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. This
helps to keep the requirements independent of the implementation mechanism. It also
ensures 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 the
code; instead they represent conceptual entities that interact to represent the behavior of
the proposed software without thinking much about implementation issues like
persistence, performance or security. Besides, we do not apply any kind of design
patterns here. Design patterns like Strategy, Abstract Factory etc come into play during
the 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 to
send 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 at
the 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 -


1b. Directed Association: Association between classes is considered to be bi-directional
by default. However we can fix the navigability of the association by using a directed
association. The arrowhead identifies the container-contained relationship.

1c. Reflexive Association: It does not need any special visual symbol. However, the
relation will point back at the same class. An example of this kind of relation is when a
class has a variety of responsibilities. For example, an employee of a company can be a
manager for another employee.

2. Aggregation: When a class is formed as a collection of other classes, it is called an
aggregation relationship between these classes. It is also called a "has a" relationship.

2a. Composition: Composition is a special kind of aggregation relationship in which the
life-cycle of the contained object strictly ends at (or before) the destruction of the
container object.

3. Inheritance/Generalization: Generalization is an "is a" relationship in which the child
class is a type of the parent class. Generalization is the basic mechanism for encouraging
reuse. The child classes "inherit" the functionality defined in the parent class.

4. Realization: In a realization relationship, one entity (normally referred to as an
interface) defines a set of functionalities as a contract and the other entity (normally
referred to as a concrete class) "realizes" the contract by implementing the functionality
defined in the contract.

Class diagrams help in identifying relationships in the space domain. For example in the
system currently under analysis, it may be helpful to capture that Group-reservation-info
and Corporate-reservation-info classes are inherited from Reservation-info class.

- 17 -


Need for Activity Diagrams
Activity diagrams are used to model the dynamic behavior of any element of an object
oriented 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 complex
in 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/join
could be intelligently used to capture information that may not be clear in the use case
specification. Activity diagrams can be a very helpful input in drawing the interaction
diagrams.

Need for Interface Requirement Specification
While designing systems that need to interface with (existing/pre-designed) external
systems, we need to ensure that the external interfaces of our modules are compatible
with the interfaces presented by the external system. The IRS is used to capture such
requirements. 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 interface
with an existing print server. In this case we document the interface provided by the print
server as follows:

interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob
void initialize (Printer p);
void print (Printer p, PrintDoc d);
void displayPrintQueue (Printer p);
void cancelPrintJob (Printer p, PrintDoc d);
} //PrintServer

Interface specification for Print Server

We 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 interface
but also the data format to be followed for interfacing with the (existing) print server(s).

- 18 -


Need for State Diagrams
State diagrams help us to capture certain requirements that may be very crucial to the
correct/efficient working of the system. Even if they may not come directly into the final
SRS, they do affect the functional/non-functional requirements. A common example can
be that of a “Software Defect Tracking” system in which we need to capture not only the
valid states (like unassigned/assigned/resolved/deferred/retired) but also the valid state
transitions.

Specifying Functional Requirements using the Class Diagram
Functional 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 should
include a short description of the need/responsibility of each class, each class-attribute as
well as each class-method.

Specifying Non Functional Requirements
Functional requirements specify the actions that the software must perform. Non-
functional requirements place restrictions on the product being developed and/or the
development process. They may also specify external constraints that the product must
meet.

Figure 8: Classification of Non Functional Requirements

- 19 -


It is usually difficult to identify non-functional requirements, unless clearly specified in
the problem statement. In such cases, it is better to probe the customer using open-ended
questions in each of the categories given in the above diagram.

Software Requirement Specification
The SRS document is the official statement of what is required of the system
developers. It is NOT a design document. To the extent possible, it should only specify
WHAT the system needs to do, rather than HOW it should do it.

Each software product company/vendor usually has its own format for documenting the
requirements. Ideally the SRS should include the following topics:
 Introduction.
 General system description.
 Specific requirements.
 Appendices.
 Index.

- 20 -

Software (requirement) analysis using uml

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (13)

Similaire à Software (requirement) analysis using uml

Similaire à Software (requirement) analysis using uml (20)

Dernier

Dernier (20)

Software (requirement) analysis using uml