Exercise 1.

To develope Problem Statement

How to Write a Problem Statement

A problem statement is a clear concise description of the issue(s) that need(s) to be addressed by

a problem solving team. It is used to center and focus the team at the beginning, keep the team

on track during the effort, and is used to validate that the effort delivered an outcome that solves
the problem statement. It has a specific form:

 Vision - what does the world look like if we solve the problem?

 Issue Statement - one or two sentences that describe the problem using specific issues. It is not
a "lack of a solution" statement. For example, our problem is that we don't have an ERP system.

 Method - the process that will get followed to solve the problem. For example, DMAIC or
Kaizen.
Exercise 2.
How to write the SRS documentation, following IEEE Std. 830.
ISM 4331, J.Zalewski, September 2003

1. General

1.1 All documents should have a title page (to include information such as: title of the project,
course name and number, team members, place, date, and other relevant information).

1.2 Table of Contents normally makes a lot of sense, so should be included as well

1.3 Number all sections in the document.

1.4 Any reference correctly included in Section 1.4 should be written as follows:

For books, reports, theses, standards, manuals, etc.:

[number] NameOfAuthor(s), TtitleOfWork, Publisher, Place, Date
(if authors’ or editors’ names are not available, it can start with a title of the
name of the Publisher)

For papers/articles:
[number] NameOfAuthor(s), TtitleOfWork, JournalName, VolumeNumber,
IssueNumber, PageNumbers (pp. first-last), Year (or Month and Year)

For papers in Conference Proceedings:

[number] NameOfAuthor(s), TtitleOfWork, Phrase “Proceedings of the” Conference
Name, Place, Date[, Publisher, Place Date]

For websites:
[number] AuthorNames(s), TitleOfWork, Company’s Name, Place, Date, URL

Note. For names of authors never use full first names, only initials!

1.5 All references from Section 1.4 have to be referred to in the text (using [number]
notation)

1.6 Do not end section titles with colons.

1.7 Every figure/diagram should have a caption (number and titile). Place it underneath
the figure/diagram.

1.8 Every table should have a number and title, placed above the table.

1.9 “Shall/Must” phraseology should not be used in unless it is requirement. This means
that normally it is not used in sections 1 or 2.
2. Writing “Introduction”

- In Section 1.1 “Purpose”, describe the purpose of this document, not the purpose of
the software being developed.
- In Section 1.2 “Scope”, describe the scope of this document, not the scope of the
software being developed.
- In Section 1.5 “Overview”, provide an overview of this document, not the overview of
the software being developed.
- Definitions, in Section 1.4, should be write using the following template:
word_defined. <in lower case, ended with a dot “.”> Followed by a definition.
For example:
user. The person, or persons, who operate or interact directly with the product.

3. Writing “Overall Description”

- a Context Diagram is mandatory.

- other important characteristics are: Product Perspective, product Functions, User
Characteristics, Constraints, Assumptions and Dependencies.

4. Writing “Specific Requirements”

- Never specify the Operating System or Language in the SRS, unless the customer
demands doing so. These are strictly implementation issues, and well designed software
can be implemented in any specific programming language to run under any specific
operating system on any specific hardware platform.

- Specific Requirements Section should be split into:

* “External Interfaces” derived from the Context Diagram
* “Functional Requirements” that should be further split into “Input Requirements”
(related to user inputs, commands, etc.), “Output Requirements” (mostly related to the
GUI), “Input/Output Requirements” (if they cannot be separated), and “Processing
Requirements”
* “Non-Functional Requirements”, such as performance, reliability, safety, security, etc.
* “Design Constraints”, normally related to software and hardware limitations (OS,
platform, stand-alone or networked, network protocols, standards, etc.);
* “Database Requirements” – can be combined with “Design Constraints”.

- Use Case Diagrams have to be included in most sections, specifically in the “Functional
Requirements” section. Several Use Case Diagrams have to be presented, including
specific scenarios, how the system will respond to certain user/operator requests or
commands, or network behavior.

5. Other
- End your SRS document by the following line (centered across the page):
*** End of the SRS ***
Exercise 3.
Identify Use Cases and develop the Use Case model

Creating a new RR model

 When you open RR a “Create new model” window will appear with various templates. Click
Cancel. We won’t be using a template.

The Side (Left) Window

 There are four folders—Use Case View, Logical View, Component View, Deployment
View. In this tutorial you will be using only Use Case View

Notice the Main (Right) Window

 The main window defaults to Logical View, Main Class Diagram. This is annoying because
this is not always where you want to be. If you aren’t careful you could put your Use Case
diagram here by accident.

Associations
 In Rational Rose 2001 you will notice an “Associations” icon for each package in the use
case view. Once you have set up use cases and created use case diagrams “Associations” will
contain information about all of the associations between use cases and actors. We will not
be referring to this feature.

Save Often
 Save often, save often, save often
Introduction

 This tutorial uses an example of a Car Repair shop. We will use two business areas—Vehicle
Service and Customer Service. We need to create separate packages for each of these work
areas and we need to create a main use case diagram that shows all of the packages.

Create packages:
 Click on Use Case View in the side window.
 Right click. A list of options will appear.
 Click on New, then Package. In the folder name area key in Vehicle Service.
 Repeat the above steps creating a package named Customer Service.

Create a main Use Case Diagram:

 Click on the + beside Use Case View in the side window (if it is not already expanded). An
entry called Main will show up in the Use Case View folder. This is the Main Use Case
diagram. Notice the icon. This same icon will be used for all Use Case diagrams.
 Double click on Main. An empty use case diagram will appear in the main window.
 In the side window click on the Vehicle Service folder and drag it to the use case diagram.
Do the same for the Customer Service folder.
 Your Main use case diagram will now contain two packages. This is a high level reference—
it shows all of the business areas that are part of your model.

CREATING USE CASE DIAGRAMS FOR EACH BUSINESS AREA

Introduction
 As part of creating Use Case Diagrams we are going to create empty Use Case Diagrams
then create and add Actors and Use Cases.

Create a use case diagram for each business area:

 Click on the Vehicle Service folder in the side window.
 Right click. A list of options will appear.
 Click on New, then Use Case Diagram. In the use case diagram name area key in Vehicle
Service.
 You now have an empty use case diagram in your Vehicle Service package.
 Repeat the above steps but this time create an empty use case diagram in your Customer
Service package.

Create Actors and add them to the use case diagrams

 Let’s create two actors—Service Advisor and Customer Service Rep and put them into the
appropriate use case diagram.
 Click on the Use Case View folder in the side window.
 Right click. A list of options will appear.
 Click on New, then Actor. In the actor name area key in Service Advisor.
 Double click on the Vehicle Service use case diagram so that the empty diagram appears in
the main window.
 In the left window click on the Service Advisor actor and drag it into the use case diagram.
Your use case diagram should now have an actor in it.
 DRAG & DROP METHOD: There is an alternate way to add actors. Display a use case
diagram in the main window. Click on the actor icon on the toolbar then click on the use
case diagram. The Actor will appear in the main window with no name. Key in a name.
 Now use either method described above to add a Customer Service Rep actor to the
Customer Service use case diagram.

To Delete Actors
 If you want to delete an actor from a use case diagram, click on it in the diagram and use the
DEL key.
 If you want to delete an actor from the whole model, click on the actor name in the side
window, right click and click on Delete. The actor will be deleted from the model.

Create Use Cases in the Use Case Diagram

 Double click on the Vehicle Service use case diagram. The diagram should appear in the
main window.
 Click on the use case icon in the toolbar (the ellipse) then click on the diagram. The Use Case
will appear in the diagram with no name. Key in a name—Maintain Vehicle Information.
Add another use case called Maintain Service Information.
 ALTERNATE METHOD: In the side window click on Use Case View, right click, select
Add, then Use Case. An unnamed Use Case will be added. Key in a Use Case name. To get
the Use Case into a diagram, display the diagram in the main window, click on the use case
in the side window and drag it into the diagram.
 Now use either method described above to add two use cases to the Customer Service use
case diagram—Maintain Customer Information and Track Customer Calls.

To Delete Use Cases

 Use the same method as for actors.

Associate Actors to Use Cases

 Use the “association” icon (solid line like an upside down L with no arrows). If you don’t see
this symbol on your toolbar, right click on the toolbar (right on the tools), select customize,
and then Add it from the left to the right.
 To associate an Actor to a Use Case, click on the association icon, click on the Actor, drag to
the appropriate Use Case and let go.
 Display the Vehicle Service use case diagram in the Vehicle Service package. Associate the
Service Advisor with both use cases in the diagram.
 Display the Customer Service use case diagram in the Customer Service package. Associate
the Customer Service Rep with both use cases in the diagram.

Detailed Association Icons

 NOTE: in Rational Rose 2001 when you add an association you will notice that a detailed
association icon appears on any use case or actor involved in the association—click on +
beside the use case or actor to see these. These icons will show you all actors and use cases
associated to each use case and actor.
To Delete an Association

 To delete an association between Actor and Use Case, click on the association, then use the
Delete key on your keyboard, OR after you have selected the association go to the Edit menu
and click on Delete or Delete from Model, OR select the detailed association icon in the side
window, right click and select Delete.

To Add Stereotypes to Associations

 NOTE: For stereotype associations you should use the “Dependency or Instantiates” tool
(dotted line with arrow).
 Double Click on an association. In the Stereotype box either select from the dropdown menu
or key in the association stereotype name then click OK. The association stereotype—e.g.
<<uses>>, <<extend>>--will appear on the association.
 If you have added a stereotype it will be part of the dropdown list in the Stereotype box; you
can just select it instead of re-keying it.

PART III ADDING USE CASE DESCRIPTIONS TO USE CASES

Introduction
 First you will create some blank use case descriptions, then you will associate them to the
appropriate use cases

Create Use Case Descriptions using MSWord

 Create an empty Word file for each use case in your model. Name these four files as follows:
Maintain Service Information.doc, Maintain Vehicle Information.doc, Maintain Customer
Information.doc, and Track Customer Calls.doc.
 Create the directory c:\temp\group01. (Note: When you are creating your work packages you
will name this directory according to what group you are in. For example if you are in
group23 you would create a c:\temp\group23 directory).
 Move all of these files into the c:\temp\group01 directory.

Add the Use Case Description documents to the Model

To add the use case description to the model you associate each description file with the
appropriate use case:

 Display the Vehicle Service use case diagram.

 Double click on the Maintain Service information use case in the diagram. A Use Case
Specification widow will appear—select the Files tab.
 Right click in the blank portion. Select Insert File. Key in the name and location of the
Maintain Service Information.doc file, or use the Browse key.
 Click on OK.
 On the left side window you will see that the Maintain Vehicle Information use case has a +
beside it (if it is not already expanded). Click on this and you will see that the Maintain
Service Information.doc file has been added. You can double click on it and the file will
open. You can also double click on the use case in the diagram, click on the Files tab then
double click on the file name and the file will open.
 ALTERNATE METHOD: In the side window click on the use case you want (not the use
case diagram but the use case), right click, select New, then File. Select the location and file
name and click on Open. The file will be associated.
 Add the other three use case descriptions to the model using either method described above.

To Remove a File

 Click on the file name either in the Use Case Specification window or in the left side
window, then right click and select Delete. NOTE that this will only remove the file from the
diagram, it will not actually delete the file.

USE CASE DIAGRAM

USE CASE:

The definition of use case could not be understood without defining scenario.

SCENARIO: Scenario is nothing but a sequence of steps describing an interaction between a

user and a system.

USE CASE: A use case now could be defined as the set of scenarios tied together by a common
user goal. A use case could also be described as a sequence of actions that provide something of
measurable value to an actor and is drawn as a horizontal ellipse.

Use cases are essential tool in requirements capture and in planning and controlling an iterative
project.
Every use case is a potential requirement ,and until we have captured a requirement, we cannot
plan to deal with it.
Use cases represent an external view of the system.

A simple format for capturing a use case involves describing its primary scenario as a sequence
of numbered steps and the alternatives as variations on that sequence.

The amount of details we need depends upon the risk in the use case.
The more risk, the more detail you need.
Use case diagram is a diagram introduced for the visualization of the use cases.
ACTORS

An actor is a role played by the user with respect to the system. An actor is a person,
organization, or external system that plays a role in one or more interactions with your system.
Actors are drawn as stick figures. A user may play more than one role.

When dealing with actors, it is necessary to think about roles rather than people or job titles.

Actors carry out use cases. A single actor may perform many use cases, a use case may have
several actors performing it.

Actors need not be humans, they could even be a computer, or an external system that need some
information from the current system.
A good source for identifying the use cases is the external events. Maximum the external events
identified and the more use cases you could find out.

USE CASE RELATIONSHIPS

The ASSOCIATION between actors and use cases are indicated in use case diagrams by solid
lines. An association exists whenever an actor is involved with an interaction described by a use
case. Associations are modeled as lines connecting use cases and actors to one another, with an
optional arrowhead on one end of the line. The arrowhead is often used to indicate the direction
of the initial invocation of the relationship or to indicate the primary actor within the use case.

The INCLUDE relationship occurs when you have a chunk of behavior that is similar across
more than one use case and you don't want to keep copying the description of that behavior.

The GENERALIZATION relationship is used when one use case that is similar to another use
case but does a bit more.
It gives us another way of capturing scenarios.

The EXTEND relationship is something similar to generalization but with more rules to it.
In this the extending use case may add behavior to the base use case, but this time the base use
case must declare certain extension points and the extending use case may add additional
behavior only at those extension points.

A use case may have many extension points and an extending use case may extend one or more
of these extension points.
Both generalization and extend allow us to split up a use case.

We can split the use case if it starts getting too complicated..

Following rules could be applied for splitting the use case:

1.Use include when you are repeating yourself in two or more separate use cases and you want to
avoid repetition.
2.Use generalization when you are describing a variation on normal behavior and you wish to
describe it casually.
3.Use extend when you are describing a variation on normal behavior and you wish to use the
more controlled form, declaring your extension
points in your base use case.

PROCEDURE FOR DRAWING A USE CASE DIAGRAM

We should ask how the actors interact with the system to identify an initial set of use cases.
Then, on the diagram, we connect the actors with the use cases with which they are involved. If
an actor supplies information, initiates the use case, or receives any information as a result of the
use case, then there should be an association between them.As we begin to notice similarities
between use cases, or between actors, we can start modeling the appropriate relationships
between them.

Fig below shows the Example Use case Diagram :