Requirements as UsecasesCapturing the

REQUIREMENT

ANALYSIS

DESIGN

IMPLEMENTATIONTEST

Introduction

Major effort in requirements : Develop a Model of the System to be built. Employ usecases to build such a model.

Functional Reqs are structured as usecases. Non Functional Requirements are specific to a

single usecase. Remaining Non-Functional requirements are kept

in a separate document called the supplementary requirements.

Importance of Usecase

Offers a systematic and intuitive way to capture the functional requirements.

By using usecases the analysts are forced to think in terms of who users are and what business or mission needs can be fulfilled through them.

It drives the entire development process.

The Requirements Workflow

The artifacts created in the requirements workflow.

The artifacts created in the requirements workflow. The workers participating in the requirements workflow. The requirements capture workflow, including each

activity in more details

Artifacts

Use Case Model Actors Use cases

Flow of Events Special Requirements

Architecture Description Glossary

The Use Case Model

* *

1

Use Case Model

Use Case System

Actor Use Case

Artifact - The Use Case Model

Agreement on requirements between developers and customers, i.e, the condition or capability to which the system must conform..

Provides essential input for analysis, design and testing. A use-case model is the model of the system containing

actors and their usecases and their relationships. For large number of usecases in a system, packages may

be introduced in the model to manage its size. Presents Model in diagrams that presents the actor and

usecases from different viewpoint and different purpose.

Artifact - Actor

Parties outside the system that collaborate with the system Often corresponds to workers in a business. An actor plays one role for each case with it collaborates.

Each time a specific user interacts with the system, the corresponding actor instance is playing the role.

An instance of an actor is thus a specific user interacting with the system.

Any entity that conforms to an actor can act as an instance of the actor.

Artifact - Actor (TQ – Pg21)

Actors are not a part of the system. Anyone or anything that must interact with the

system. An Actor may

Only input information to the system. Only receive information from the system. Input & receive information to and from the system.

Artifact - Identifying Actors (TQ – Pg21)

Typically found in the problem statement. Conversation with the customers or Domain Experts. By asking the following questions :

Who is interested in a certain requirement? Where in the organization is the system used? Who will benefit from the use of the system? Who will supply, use and remove the information from the system? Who will support and maintain the system. Does the system use an external resource. Does one person play several different roles? Do several people play the same role. Does the system interact with a legacy system?

Artifact - Usecase

Each way a actor uses the system is represented as a usecase.

Are “chunks” of functionality that the system offers to add a result of value to its actors.

Sequence of actions, including alternatives of the sequence, that the system can perform, interacting with actors of the system.

Specification of the behavior of the dynamics of the system.

Artifact - Usecase

Usecase is a classifier – It has attributes and operations.

Usecase description include the following: State Chart Diagrams Activity Diagrams Collaboration Diagrams Sequence Diagrams.

Usecase Instance

Execution of usecase. Interacts with the actor instance and performs a

sequence of actions as specified by the usecase. This sequence is specified by a state chart or

activity diagram.. Many paths are possible through a usecase and

many are very similar. These are the alternatives through the Usecase.

Path in a usecase

Path through a use case looks as follows: The Use-Case is instantiated and put in a start state. Invoked by external message from actor. It transitions to another state by performing a sequence

of actions. Such a sequence contains internal computations, selection of path and message output.

It awaits, in its new state, another message from an actor.

It is invoked again by a new message and so on. It goes over many states until the usecase is terminated.

Usecase instance - Characteristics

Have attributes that is manipulated during usecase execution. Usecase instance is atomic. A Usecase instance does not interact with other instances. The only interaction that happens in a Usecase is between

Actor instances & Usecase instances. The interference issues between different uses of a system is

resolved in the Analysis and design phase when we realize these usecases as collaboration classes and subsystems.

Usecases - Flow of Events

Describes what the system does when a specified usecase is performed.

Also specifies how the system interacts with actors when the usecase is performed.

Flow of events for each usecase can be captured as a separate textual description of the use-case's sequence of action.

Description includes a set of sequence of actions that are suitable to modify, review, design, implement and test together and to describe as a section or subsection in the user manual.

Usecase – Special Reqmnts.

Textual description that collects all requirements on a usecase.

Primarily non-functional requirements that are related to the usecase and that are needed to be handled in subsequent workflows such as analysis, design or implementation.

Usecase – How to identify?

The following question may be used to help identify the usecases of the system.

What are the task of each actor? Will any actor create, store, change, remove or read values from the

system? What usecases will create, store, change, remove or read values from

the system. Will any actor need to be informed of certain occurrences in the

system? Will any actor need to inform the system of any external occurrences? What usecases will support and maintain the system? Can all functional requirements be performed by the usecases?

Artifact - Architectural Description

Architectural View of the usecase model depicting the architecturally significant usecases.

Should contain all usecases that describe some important and critical functionality or that involves certain requirements that must be developed early in the software cycle.

This view is used as an input when the usecases are prioritized to be developed within an iteration.

Artifact - Glossary

Used to define important and common terms. Used by the analysts when they describe the system.

Is useful in reaching a consensus among developers regarding the definition of various concepts and notations to reduce the risk of misunderstandings in general.

Can often be derived from a business model or domain model, but because it is less formal it is easier to maintain and more intuitive to discuss with users and customers.

Tends to be more focused on the system to be built instead of system’s context.

Artifact – User Interface Prototype

Helps during requirements capture to understand and specify the interaction between human actors and system.

Helps us in developing a better user interface and to understand usecases better.

Workers – System analyst

Usecase Model Actor Glossary

System Analyst

Workers – Usecase specifier

Use Cases

Usecase Specifier

Workers – User Interface Designer

User Interface Prototype

User Interface Designer

Workers – Architect

Architecture Description

Architect

Usecase Model

Architectural View

WORKFLOW

A Sequence of activities which are ordered so that one activity produced output that is used as an input for the next activity.

When workers perform activities they create and modify artifacts.

An activity may be revisited several times and each visit may entail carrying out only a fraction of the activity.

Workflow – Sequence

Perform Find Actors and usecases. Find architecturally significant usecases to

provide input to the prioritization of usecases to be developed in the current iteration.

Detail the usecases. Suggest suitable user interface for each

actor based on the usecases.

Find Actors & Usecases - Why

Delimit our system from its environment. Outline who and what will interact with the

system and what functionality is expected from the system.

Capture and define a glossary of common terms that are essential for creating a detailed description of the system’s functionality.

Find Actors & Usecases - Activity

Finding the actors Finding the usecases Briefly describing the usecase Describing the usecase model as a whole.

The above steps are performed concurrently.

Find Actors & Usecases - Activity

Business Model

System Analyst

Supplementary Requirements

Feature List

Use-Case Model

[Outlined]

Glossary

Find Actors and Use Cases

Find Actors and Usecases - Example

Find Actors and Usecases - Example

Briefly describing each usecase

Identify the usecases and explain them in a few words.

Later describe each usecase briefly in a few sentences.

Later a step by step description of what the system needs to do when interacting with its actors.

Refer to Page 150 of the book for an Example.

Describing the usecase model as a whole

Prepare diagrams and descriptions to explain the use case model as a whole, particularly how the usecase relate to each other and the actors.

To ensure consistency while describing several usecases concurrently, it is practical to develop some glossary of terms.

Terms are derived from classes in domain or business model.

Refer to Page 151 of the book for an Example.

Prioritizing Usecases

Determine which one needs to be developed in earlier iterations and which can be developed in later iterations.

The results are captured in architectural view of the usecase model.

Prioritizing Usecases

Business Model

Architect

Supplementary Requirements

Feature List

Architectural Description view of the

usecase modelPrioritizing

Detailing a Usecase

Describe flow of events in details including how the usecase starts, ends and interacts with actors.

With usecase model and associated usecase diagrams as starting point, the individual usecase specifiers can now describe each usecase in details.

Detail the step-by-step description of each usecase into a precise specification of the sequence of actions.

Detailing a Usecase

How to structure the description to specify all the alternative paths to the usecase.

What to include in a usecase description. How to formalize the use-case description

when necessary.

Detailing a Usecase

Use-Case Specifier

Supplementary Requirements

Use Case [Detailed]

Detail a Usecase

Use-Case Model

Glossary

Structuring a Usecase Desc.

Defines the state that use-case instances may enter and possible transition between those states.

Each such transition is a sequence of actions that are performed by a usecase instance when triggered by an event such as a Message.

Artifact – State Transition Diagram.

What to include in Usecase Desc.

Start State as Pre-condition How and When the use-case starts Required order in which order must be performed. How and when the usecase ends. Post Conditions or End States. Paths of execution that are not allowed. Alternative Paths. System Interaction with the actors and what they exchange. Usage of objects, values and resources in the system. Describe what the system & actors do.

Formalizing the Usecase Desc When describing a usecase, ensure that we cover

all possible cases. When usecases become very complex, a structured

description technique may be needed.

State Charts Activity Diagrams Interaction Diagrams

Prototype User Interface

Build a prototype of the User Interface. Start with a use case and try to discern what is needed

from the user interfaces to enable usecases for each actor (Logical User-Interface Design).

Then Create Physical User Interface design and develop prototypes that illustrates how how users can use the system to perform the usecases.

Result of this activity is a set of user-interface sketches and user-interface prototypes that specify the look and feel of the user Interface for actors.

Structuring Use Case Model

To Extract general and shared descriptions of functionality that can be used by more specific use-case descriptions.

Extract additional and optional description of functionality that can extend more specific use-case description.