Unit II

Inception

Artifacts in inception, Understanding requirements - the FURPS model, Understanding Use case
model - introduction, use case types and formats, Writing use cases - goals and scope of a use
case, elements /sections of a use case, Use case diagrams, Use cases in the UP context and UP
artifacts, Identifying additional requirements, Writing requirements for the case study in the use
case model

2.1 Artifacts in inception, Understanding requirements - the FURPS model

Table lists common inception artifacts and indicates the issues they address. Subsequent chapters
will examine some of these in greater detail, especially the Use-Case Model. A key insight
regarding iterative development is to appreciate that these are only partially completed in this
phase, will be refined in later iterations, and should not even be created unless it is deemed likely
they will add real practical value. And since it is inception,the investigation and artifact content
must be light.

E.g: the Use-Case Model may list the names of most of the expected use cases and actors, but
perhaps only describe 10% of the use cases in detail—done in the service of developing a rough
high-level vision of the system scope, purpose, and risks.

Note that some programming work may occur in inception in order to create"proof of concept"
prototypes, to clarify a few requirements via Ul-oriented prototypes, and to do programming
experiments for key "showstopper" technical questions.

Artifact Comment
Supplementary Specification Describes other requirements.

Glossary Key domain terminology.

Describes the high-level goals and constraints, the business case, and
Vision and Business Case
provides an executive summary.
Risk List & Risk Management Describes the business, technical, resource, schedule risks, and ideas
Plan for their mitigation or response.
Describes the functional requirements, and related non-functional
Use-Case Model
requirements.
Low-precision guess for elaboration phase duration and effort. Tools,
Phase Plan & Software
people, education, and other resources.
Development Plan
A description of the customized UP steps and artifacts for this project.
Development Case
In the UP, one always customizes it for the project.
Prototypes and proof-of-
To clarify the vision, and validate technical ideas.
concepts
Describes what to do in the first elaboration iteration.
Iteration Plan

These artifacts are only partially completed in this phase. They will be iteratively refined in
subsequent iterations. Name capitalization implies it is an officially named UP artifact.

Requirements are capabilities and conditions to which the system and more broadly, the project
must conform [JBR99]. A prime challenge of requirements work is to find, communicate, and
remember (that usually means record) what is really needed, in a form that clearly speaks to the
client and development team members.

The purpose of Requirements is:

• To define a user-interface for the system, focusing on the needs and goals of • To define the
boundaries of (delimit) the system.

• To provide a basis for planning the technical contents of iterations.

the users.

• To provide a basis for estimating cost and time to develop the system.

• To provide system developers with a better understanding of the system requirements.

The UP promotes a set of best practices, one of which is manage requirements. It doesn’t refer to
the waterfall attitude of attempting to fully define and stabilize the requirements in the first phase
of a project, rather in context of naturally changing and uncertain stakeholder wishes that "a
systematic approach to finding, documenting, organizing, and tracking the changing
requirements of a system" where in short, doing it skillfully and not being careless. Note the
word changing', the UP embraces change in requirements as a fundamental driver on projects.
Determining is another important term that is, requirement gathering via techniques like use case
writing and requirements workshops.
As indicated in the above , one study of factors on challenged projects disclosed that 37% of
factors related to problems with requirements, making requirements issues the largest single
contributor to problems. Accordingly,masterful requirements management is important. The
waterfall response to this data would be to try harder to polish, stabilize, and freeze the
requirements before any design or implementation, but historically this is considered to be a
losing battle. The repeated response is to use a process which holds the change and feedback as
core drivers in finding requirements.

FURPS

There are many different kinds of requirements. One way of categorizing them is described as
the FURPS+ model [GRA92], using the acronym FURPS to relate the major categories of
requirements with subcategories as shown below.They are as follows:

Functional

Functional requirements may include:

• Capabilities

• Security.

• Feature sets

Usability

Usability requirements may include such subcategories as:

• Human factors

• Aesthetics

• Training materials.

• Consistency in the user interface

• Wizards and agents

• Online and context-sensitive help

• User documentation

Reliability

Reliability requirements to be considered are:

• Predictability

• Frequency and severity of failure

• Mean time between failure (MTBF).

• Recoverability

• Accuracy

Performance

A performance requirement imposes conditions on functional requirements. For example, for a

given action, it may specify performance parameters for:

• Resource usage.

• Availability

• Speed

• Efficiency

• Throughput

• Response time

• Accuracy
• Recovery time

Supportability

Supportability requirements may include:

• Compatibility

• Extensibility

• Testability

• Adaptability

• Localizbility (internationalization).

• Configurability

• Serviceability

• Maintainability

• Installability

Design Requirement

A design requirement, often called a design constraint, specifies or constrains the design of a
system.

Implementation Requirement

An implementation requirement specifies or constrains the coding or construction of a system.

Examples are:

• Resource limits

• Implementation languages

• Policies for database integrity

• Required standards

• Operation environments.

Physical Requirement
A physical requirement specifies a physical characteristic that a system must possess. For
example,

• Weight.

• Shape

• Material

• Size

This type of requirement can be used to represent hardware requirements, such as the physical
network configurations required.

The "+" in FURPS+ indicates ancillary and sub-factors, such as:

• Interface

Constraints imposed by interfacing with external systems.

An interface requirement specifies:

An external item with which a system must interact constraints on formats, timings, or other
factors used by such an interaction.

• Implementation

Resource limitations, languages and tools, hardware.

• Packaging

for example, a physical box.

• Operations

System management in its operational setting.

• Legal

licensing and so forth.

Requirements are categorized as functional (behavioral) or non-functional .

Functional Requirements

Functional requirements specify actions that a system must be able to perform, without taking
restrictions into consideration. These are often best related in a use-case model and also in use
cases. Functional thus identifies the input and output behavior of a system.

Functional requirements are explored and recorded in the following ,

System features list of the Vision artifact.

Use-Case Model

Non-functional Requirements

Requirements which are not functional, like the ones that are listed below, are sometimes known
as the non-functional requirements. Many requirements are non-functional, and they describe
only attributes of system or attributes of system environment.While some of these can be
captured in use cases, those that may not be specified in Supplementary Specifications.

Other requirements may be noted in the use cases they relate to, or in the Supplementary
Specifications artifact.

A complete definition of the software requirements, use cases, and Supplementary Specifications
can be bundled together to define a Software Requirements Specification (SRS) for a specific
"feature" or other subsystem grouping.

2.2 Understanding Use case model - introduction, use case types and formats, Writing use cases -
goals and scope of a use case, elements /sections of a use case, Use case diagrams
A use case is a text stories of an actor using a system to meet the aimed goals.

An actor is something with behavior and have responsibilities.

To carry out certain responsibilities, an actor sets goals

• Primary actor has unsatisfied goal and needs system assistance.The primary actor is similar to a
stake holder.

• Secondary actor provides assistance to satisfy these goal.

A scenario is a specific sequence of actions and interactions between the actors and the system.

It is one particular story of using a system, or one path that is through the use case.

Types and formats of Use cases.

Black-Box Use Cases and System Responsibilities

Black-box use cases are the most common and recommended kind; they does not detail the
internal workings of the system, its components, or design. Rather, the system is described as
having responsibilities, that is a common uniform symbolic theme in object-oriented thinking—
software elements have responsibilities and collaborate with the other elements which have
responsibilities.By means of defining the system responsibilities with black-box use cases, it is
possible to specify what the system should do without deciding how it will do the design. Very
well, the definition of "analysis" versus "design" is sometimes summarized as "what" versus
"how." This is an important theme in a better software development: During requirement
analysis it is good to avoid making the "how" decisions, and specify the external behavior for the
system, as a black box. Later, during design, create a solution which meets the specification.

The system generates a SQL INSERT statement for sale.

Black-box style Not

The system writes the sale to a data-base :
The system records the sale.
 The system generates a SQL INSERT statement for the
sale.

Formality Types

Use cases can be written in different formats, depending on the requirement. Additionally use
cases are written in varying degrees of formality.

Degrees of formality:

• Casual—informal paragraph format. Multiple paragraphs that cover several scenarios. The
prior Handle Returns example was casual.

• Brief—terse one-paragraph summary, usually of the main success scenario. The prior Process
Sale example was brief.

• Fully dressed—the most elaborate. All steps and variations are written in detail, and there are
supporting sections, such as preconditions and success guarantees.

Writing use cases

Use cases has the following elements.They are:

Name – A clear verb/noun or actor/verb/noun descriptor that communicates the scope of the use
case.

1.Actors – A list of the types of users who can engage in the activities described in the use case.
Actor names should not correspond to job titles.

2.Exception Flows – The things that can happen that prevent the user from achieving their goal,
such as providing an incorrect username and password.

3. Brief Description – A brief paragraph of text describing the scope of the use case.

4.Alternate Flows – Capture the less common user/system interactions, such as being on a new
computer and answering a security question.

5.Basic Flow – The set of steps the actors take to accomplish the goal of the use case. A clear
description of what the system does in response to each user action.

6.Preconditions – Anything the solution can assume to be true when the use case begins.

7. Post Conditions – Anything that must be true when the use case is complete.

GOALS AND SCOPE OF A USE CASE

It is common to be unsure if something is a valid use case. Tasks may be grouped at many levels
of granularity, from one of few small steps, up to enterprise-level activities.

The following sections describes the simple ideas of elementary business processes and goals as
a framework for identifying the use cases for an application.

Use Cases for an Elementary Business Processes

Negotiate a Supplier Contract

Handle Returns

Log In

An argument shall be made that all of these are use cases at several levels, depending on the
system boundary, actors, and goals.

Elements of a Use Case Diagram

A use case diagram captures the business processes performed in the system. Generally, domain
experts and business analysts must be involved in writing the use cases. Use cases are created
when the requirements of a system are needed to be captured. A use case diagram is quite simple
in nature and pictures two types of elements.They are: one representing the business roles and
the other representing the business processes.

A use case is a methodology used in system analysis to clarify, identify,and organize the system
requirements. In this context, the term "system" refers to something being developed or operated,
like a mail-order product sales and service Web site. Use case diagrams are employed in UML, a
standard notation for the modeling of real-world objects and also the systems.

System objectives also includes planning overall requirements, validating hardware design,
testing and debugging software products under development, creating online help reference, or
performing consumer-service-oriented task. For example, use cases in a product sales
environment includes customer relations, catalog updating, payment processing, and item
ordering. A use case diagram has four components.

The boundary, which defines system of interest in relation to the world around that.

The actors, generally individuals involved with the system defined according to their respective
roles.

The use cases, that are the specific roles played by the actors within and around system.

The relationships between and within the actors and use cases.

A use case diagram looks like a flowchart. Intuitive symbols indicates the system elements.

Consider this example:

Actors:
An actor portrays any entity which performs certain roles in the provided system. The different
roles the actor denotes are the actual business roles of the users in a system. An actor in a use
case diagram communicates with a use case. Eg: for modeling a banking application, a customer
entity indicates an actor in the application. Likewise, the person who provides service at the
counter is also an actor. However ,it is totally up to the user to consider what impact does actors
make on the functionality that he wants to model. If an entity does not affect certain piece of
functionality that the user is modeling, then it makes no sense to represent it as an actor. An actor
is represented as a stick figure in a use case diagram depicted "outside" the system boundary, as
depicted in the figure below.

An actor in a use case diagram

To identify an actor, search in the problem statement for business terms that portray roles in the
system. For example, in the statement "patients visit the doctor in the clinic for medical tests,"
"doctor" and "patients" are the business roles and may be easily identified as the actors in the
system.

Use case:

A use case in a use case diagram is a visual representation of a distinct business functionality in a
system. Here the key term is "distinct business functionality." To choose a business process as a
likely candidate for modeling as a use case, it is required to ensure that the business process is
discrete in its nature. As the first step in identifying use cases, one should list the discrete
business functions as specified in the problem statement. Each of these business functions may
be classified as a potential use case. Remember that identifying use cases is a discovery rather
than a creation. As business functionality turns clearer, the unrevealed use cases become more
easily noticeable. A use case is denoted as an ellipse in a use case diagram.

Use cases in a use case diagram

The two uses cases are shown in the above figure: "Make appointment" and "Perform medical
tests" in the use case diagram of a clinic system. As another example, consider a business
process like "manage patient records" may in turn have sub-processes such as "manage patient's
personal information" and "manage patient's medical information." Discovering these type of
implicit use cases is possible only with a thorough understanding of all business processes of the
system through discussions with the potential users of the system and the relevant domain
knowledge.

System boundary:

A system boundary defines the scope of what a system will be when it is nearly completed. A
system will not have infinite functionality. Therefore, it follows that use cases also requires to
have definitive limits defined with them. A system boundary of a use case diagram defines the
limits of system. The system boundary is denoted as a rectangle spanning all the use cases in the
system.

A use case diagram depicting the system boundary of a clinic application

The figure shows the system boundary of the clinic application. The use cases of this system is
enclosed in a rectangle. It is important to note that the actors in the system are outside the system
boundary.

The system boundary is possibly the entire system as defined in the problem statement. But this
is not the case always . For large and complex systems, each of the modules can be the system
boundary. For example,in case for an ERP system for an organization, each of the modules like
personnel, payroll, accounting, and so on, may form the system boundary for use cases particular
to each of these business functions. The entire system may span all of these modules depicting
the overall system boundary.

Association

An association is a bond between an actor and a use case. Association indicates that an actor can
perform a use case. Various actors at one use case mean that each actor can perform the use case
on his or her own and not that the actors perform the use case together:
 Association

According to UML, association means only that an actor is involved in a use case. We use
associations in a constrained manner.

Relationships in Use Cases

Use cases share various kinds of relationships. A relationship between the two use cases is
generally the dependency between the two use cases.Defining a relationship between the two use
cases is the decision of the modeler of the use case diagram. The inheriting of an existing use
case using different types of relationships reduces the overall effort needed in defining the use
cases in a system. A similar reuse formed using relationships, will be clear in the other UML
diagrams as well. Use case relationships may be one of the following:

Include:

When a use case is depicted as using the functionality of another use case in a diagram, the
relationship between the use cases is named as an include relationship. Exactly speaking, in an
include relationship, a use case includes the functionality that is described in another use case as
a part of its business process flow. An include relationship is depicted with a directed arrow
having a dotted shaft. The tip of the arrowhead points to child use case and the parent use case is
connected at the base of arrow. A key here is that the included use case could not stand alone,
i.e., one would not validate the patient record without fixing an appointment. The stereotype
"<<include>>" identifies the relationship as an include relationship.

An example of an include relationship

For example, it is seen that the functionality defined by the "Validate patient records" use case is
contained within "Make appointment" use case. Thus, whenever "Make appointment" use case is
executed, the business steps defined in the "Validate patient records" use case is also executed
following that.

Extend:
In an extend relationship between two use cases, the child use case adds to that of the existing
functionality and characteristics of the parent use case. An extend relationship is depicted with a
help of directed arrow having a dotted shaft, that is similar to include relationship. The tip of the
arrowhead points to the parent use case and child use case is connected at base of the arrow. The
stereotype "<<extend>>" identifies the relationship as an extended relationship, as shown in the
figure:

An example of an extend relationship

The figure shows an example of an extend relationship between "Perform medical tests" which is
the parent and "Perform Pathological Tests" which is the child use cases. The "Perform
Pathological Tests" use case enhances the functionality of "Perform medical tests" use case.
Necessarily, the "Perform Pathological Tests" use case is a specialized version of generic
"Perform medical tests" use case.

Generalizations:

A generalization relationship is also a parent-child relationship between the use cases. The child
use case in the generalization relationship has the hidden business process meaning, but is an
enhancement of the parent use case. In use case diagram, generalization is seen as a directed
arrow with a triangle arrowhead. The child use case is connected at the base of arrow. Tip of the
arrow is being connected to the parent use case.

An example of a generalization relationship

Both generalizations and extends seemed to be more or less similar on the face of it. But there is
a subtle difference between a generalization relationship and extend relationship. If we establish
a generalization relationship between the use cases, this implies that parent use case can be
replaced by child use case without even breaking flow of business. While, an extend relationship
between the use cases means that the child use case amplifies the functionality of the parent use
case into a specialized functionality. The parent use case in an extend relationship may not be
replaced by the child use case.

With the help of an example, things can be understood better. From the diagram of a
generalization relationship,it is seen that "Store patient records (which is the paper file)" use case
(parent )is depicted as a generalized version of the "Store patient records (computerized file)"
(child) use case. Defining a generalization relationship between the two implies that it is possible
to replace any occurrence of the "Store patient records (paper file)" use case in the business flow
of the system with the "Store patient records (computerized file)" use case without impacting any
business flow. This would mean that in future we may choose to store patient records in a
computerized file instead as paper documents without even impacting other business actions.

Now, if we had defined this as an extend relationship between the two use cases, this will imply
that the "Store patient records (computerized file)" use case is a specialized version of "Store
patient records (paper file)" use case. Hence, we would not be able to seamlessly replace the
occurrence of the "Store patient records (paper file)" use case with "Store patient records
(computerized file)" use case.

Use case diagram

Overview

To model a system ,most important aspect is to capture the dynamic behaviour. To clarify a bit in
details, dynamic behaviour implies the behaviour of the system when it is running or operating.

Therefore only static behaviour is not sufficient to model a system rather dynamic behaviour is
more important than static behaviour. In UML there are five diagrams available to model
dynamic nature and use case diagram is one of them. Now as we have to discuss that the use case
diagram is dynamic in nature there should be some internal or external factors for making the
interaction.

These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of
an application. A single use case diagram captures a particular functionality of a system.

So to model the entire system numbers of use case diagrams are used.

Purpose

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition
is too common to describe the purpose.
Because other four diagrams such as activity, sequence, collaboration and State chart are also
having the same purpose. Therefore,specific purposes which will distinguish it from other four
diagrams is considered.

Use case diagrams are used to gather the requirements of a system that includes the internal and
external influences. These requirements are mostly considered as the design requirements. Hence
when a system is analyzed to collect its functionalities use cases are prepared and actors are
being identified.

Now when the initial task is complete use case diagrams are modeled to present the outside view.

The purposes of the use case diagrams may be as follows:

Used to get an outside view of a system.

Used to gather requirements of a system.

Show the interacting among the requirements are actors.

Identify external and internal factors influencing the system.

Steps to draw Use Case Diagram

Use case diagrams are taken for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are represented in the use cases.

It is possible to say that the use cases are nothing but the system functionalities written in
organized manner. Now the second things that are relevant to the use cases are the actors. Actors
may be defined as something which interacts with the system.

The actors may be human user, some internal applications or maybe some external applications.
Shortly,when we are planning to draw a use case diagram we should identify the following items
.

1. Functionalities to be represented as an use case

2. Actors

3. Relationships among the use cases and actors.

4. Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we need to follow the following guidelines to draw an efficient use
case diagram.

5. The name of a use case is really important. So the name must be chosen in a way that it may
identify the functionalities that can be performed.
6. Give a suitable name for actors.

7.Show relationships and dependencies clearly in the diagram.

8. Do not try to include all types of relationships. Because the main purpose of the diagram is to
identify requirements.

9. Use note when ever required to clarify some important points.

The following is an example use case diagram which represent the order management system. So
from the diagram we can see that there are three use cases and only one actor which is the
customer.

The Special Order and Normal Order use cases are extended from the Order use case. Therefore
they have the extends relationship. Another important point is to identify the system boundary
that is shown in the use case diagram. The actor Customer is outside the system as it is an
external user of this particular system.

UML Use Case Diagram

Use case diagram is one of them and its specific purpose is to assemble the system requirements
and also the actors. Use case diagrams specify the events of a system and also their flows.
However use case diagram does not describes about how they are going to be implemented. Use
case diagram may be imagined as a black box where only the input, output and function of the
black box is seen.

These diagrams are used at a extremely high level of design. This high level design is refined
again and again in order to get a complete and a practical picture of the system. A well structured
use case explains the pre-condition, post-condition, exceptions. These extra elements can be used
to make the test cases while performing the testing.

While the use cases are not a good candidate for the forward and the reverse engineering ,But
they are still used slightly in a different way to make the forward and the reverse engineering.
The same is true for the reverse engineering. Still use case diagram is used differently to make it
a candidate for reverse engineering.

In forward engineering use case diagrams are used in making the test cases and in reverse
engineering use cases are used in preparing the requirement details from the existing application.

Therefore the following are the places where the use case diagrams are being used:

1.Requirement analysis and high level design.

2.Model the context of a system.

3.Reverse engineering.

4.Forward engineering.

2.3 Use cases in the UP context and UP artifacts, Identifying additional requirements

Use cases that influence many UP artifacts are shown in the figure below.
In the Unified Process, use case work is a requirements discipline activity that could be started
during a requirement workshop. Figure below offers certain suggestions on the time and space
for doing this particular work.
USE CASES WITHIN THE UP

Use cases are vital and central to the UP, that encourages the use-case driven development. This
means that:

Requirements are primarily noted in the use cases; other requirements techniques are secondary,
if used.

Use cases are an important part of the iterative planning. The work of an iteration is—in part—
defined by choosing some use case scenarios, or the entire use cases. And the use cases are a key
input to this estimation.

Use-case realizations drive the design. This means, the team designs collaborating the objects
and subsystems in order to perform or realize the use cases.

Use cases often influence the organization of user manuals.

2.3.1 Writing requirements for the case study in the use case model

The Use case model describes about proposed functionality of the new system. A Use case
represents a discrete unit of interaction between a user and system.
A Use case is a single unit of meaningful work.For eg: login to system, register with the system
and create the order are all the Use cases.

Each Use case has a description that describes the functionality that will be built in the proposed
system.

A Use case may 'include' another Use case's functionality or 'extend' another Use case with its
own behavior.

Use cases are typically related to 'actors'. An actor is a machine or human entity that interacts
with the system to perform meaningful work.

Use case Model

An actor is a user of the system. This includes both human users and other computer systems. An
actor uses a Use case to perform some piece of work which is of value to the business.

The set of Use cases an actor has access to defines their overall role in the system and the scope
of their action.
 Diagrammatic representation of an actor

The formal specification of a Use Case includes:

1.Requirements:

These are the formal functional requirements that a Use case must provide to the end user. They
correspond to the functional specifications found in structured methodologies.

A requirement is a contract that the Use Case will perform and provide some action or some
value to the system.

2.Constraints:
Constraints are the formal rules and limitations that a Use case operates under, and this also
includes pre, post and invariant conditions.

A pre-condition specifies what must have already occurred or be in place before the Use case
may start.

A post-condition specifies which will be true once the Use case is complete. An invariant
specifies which will be true throughout the time the Use case operates.

3.Scenarios:

Scenarios are formal descriptions of the flow of events that occurs during a Use case instance.
These are usually described in text and correspond to a textual representation of the sequence
diagram.