Purpose

To establish and maintain agreement with the customers and other stakeholders on what the system should do.

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

To define the boundaries of (scope) the system.

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

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

To define a user-interface for the system, focusing on the needs and goals of the users.

Requirement discipline-UPEDO

Analyze and understand the Problem are focused on during the inception phase of a project.

Define and Refine the System Definition during the Elaboration phase.

Manage the Scope of the System and Manage Changing Requirements are done continuously throughout the project.

Requirement activities

Requirements Artifacts

Requirement discipline-Actor

To fully understand the system's purpose you must know who the system is for, that is, who will be using the system. Different user types are represented as actors.

An actor instance is someone or something

outside the system that interacts with the system(exchanges data with the system). An actor can be :

– a user, – external hardware, – or another system.

An actor instance

Ivar and Mark are operators of a recycling machine. When they are using the machine each is represented by an instance of the actor Operator

The difference between an actor and an individual system user ? An actor represents a particular class of user rather than an actual user. Several users can play the same role, which means they can be one and the same actor. In that case, each user constitutes an instance of the actor.

The same user can also act as several actors (that is, the same person can take on different roles).

Who will use the system ? How can you categorize them?

It is often a good habit to keep a few individuals (two or three) in mind and make sure that the actors you identify cover their needs.

Usefull questions to have in mind : •Who will supply, use, or remove information?•Who will use this functionality?•Who is interested in a certain requirement?•Where in the organization is the system used?•Who will support and maintain the system?•What are the system's external resources?•What other systems will need to interact with this one?

How to find actors

How to find actors

Several different aspects of a system's surroundings

• Users who execute the system's main

functions.

• Users who execute the system's

secondary functions, such as system

administration.

• External hardware the system uses.

• Other systems interacting with the

system

Define the scope of the system Finding the actors also means that you establish the

boundaries of the system, which helps in understanding the purpose and extent of the system. Only those who directly communicate with the system need to be considered as actors.

If you are including more roles than that in the system's surroundings, you are attempting to model the business in

which the system will be used, not the system itself.

                                                                                                                                                                         

                                                                                                               

.

If you are building an airline booking system to be used at a travel agent, the actor would be travel agent. The traveler doesn't interact directly with the system, and is therefore not an actor.

If you are building a booking system that will allow users to connect via the Internet, the traveler will interact directly with the system and is therefore an actor to it.

Actor CharacteristicsThe characteristics of an actor might

influence how the system is developed, and in particular how an optimally usable user interface is visually shaped.

The actor characteristics include:

The actor's scope of responsibility.

The physical environment in which the actor

will be using the system. The number of users

represented by this actor.

The frequency with which the actor will use the

system. The actor's level of domain knowledge

Actor Characteristics

The actor's level of general computer experience.

Other applications that the actor uses. Borrowing

user-interface concepts from these applications will

shorten the actor's learning time and decrease his

memory load, since the actor is already familiar with

these concepts.

General characteristics of the actors, such as level of

expertise (education), social implications (language),

and age. These characteristics can influence details of

the user interface, such as font and language.

Use case

• A use-case instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.

A use case should make sure that an actor can perform a task that has an identifiable value.

– For example, "Enter Personal Identification Number in an ATM machine" should not be modeled as a separate use case for the ATM machine, since no one would use the system to do just this.

• A use case defines a set of use-case instances

How to Find Use CasesFollowing is a set of questions that are useful when identifying use

cases:

For each actor you have identified, what are the tasks in which

the system would be involved?

Does the actor need to be informed about certain occurrences in the

system?

Will the actor need to inform the system about sudden, external

changes?

Does the system supply the business with the correct behavior?

Can all features be performed by the use cases you have

identified?

What use cases will support and maintain the system?

What information must be modified or created in the system?

Use case• How a Use Case Evolves ?

In early iterations in elaboration, only a few use cases (those that are considered architecturally significant) are described in any detail beyond the brief description

• Are All Use Cases Described in Detail? No need a detailed description of the flow of events, a step-

by-step outline is quite enough . Ex : retrieval of some data from the system

• The Scope of a Use Case Is a set of user-system interactions, or dialog, is one or

several use cases ? Use case should be of value for the actor

• How Use Cases Are Realized A use case describes what happens in the system when an

actor interacts with the system (flow of events)to execute the use case. NOT how the system internally performs its tasks in terms of collaborating objects.

• Name : what is achieved during interaction with the actor(s). Example: withdraw money

Flow of EventsThe Flow of Events should describe the use case's flow of

events clearly .It should present what the system does, not how the system is designed to perform the required behavior.

Guidelines for the contents of the flow of events are:Describe how the use case starts and endsDescribe what data is exchanged between the actor and

the use caseDo not describe the details of the user interface, unless

it is necessary to understand the behavior of the system. Describe the flow of events, not only the functionality. To

enforce this, start every action with "When the actor ... "

Describe only the events that belong to that use caseDetail the flow of events-all "whats" should be answered.

Remember that test designers are to use this text to identify test cases.

Be sure to use the exact same terms in the different use cases (same meaning)

Manage common terms in a glossary

Flow of Events - StructureThe two main parts of the flow of events are :

The basic flow of events :. The basic flow of events should cover what "normally" happens when the use case is performed. The alternative flows of events The alternative flows of events cover behavior of optional or exceptional character in relation to the normal behavior, and also variations of the normal behavior

The typical structure of the flow of events. The straight arrow represents the basic flow of events, and the curves represent alternative paths in relation to the normal. Some alternative paths return to the basic flow of events, while others end the use case

It can be useful to use the notion of precondition and postconditionto clarify how the flow of events starts and ends. However, only use it if it is perceived as adding value by the audience of the use case.

Preconditions and Postconditions

Example:A precondition for the use case Cash Withdrawal in the ATM machine:

The customer has a personally-issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.

A postcondition for the use case Cash Withdrawal in the ATM machine: At the end of the use case, all account and transaction logs are balanced, communication with the banking system is reinitialized and the customer has been returned his card.

How the Use-Case Model Evolvesa) Both the actors and the use cases are found by using the

requirements of customers and potential users as vital information.

b) As they are discovered, the use cases and the actors should be briefly described.

c) Before the use cases are described in detail, the use-case model should be reviewed by the customer to verify that all the use cases and actors are found, and that together they can provide what the customer wants.

d) In an iterative development environment, you will select a subset of use cases to be detailed in each iteration.

e) Each use case should describe how the system interacts with the actors and what the system does in each individual case.

f) Finally, the completed use-case model (including the descriptions of use cases) is reviewed, and the developers and customers use it to agree on what the system should do.

Avoiding Functional Decomposition

It is common that the use-case model degenerates into a functional decomposition of the system.

Example:"Enter Personal Identification Number in an ATM machine" should not

be modeled as a separate use case for the ATM machine, since no one would use the system to do just this. A use case is a complete flow of events that results in something of value to an actor.

To avoid functional decomposition, you should make sure that the use-case model helps answer questions like:

What is the context of the system?Why is the system built?What does the user want to achieve when using the system?What value does the system add to the users?

Non-Functional Requirements Introduction:

It is quite easy to see that use cases are a very good way of capturing functional requirements on a system. But what about the non-functional requirements?

What are they and where are they captured? Non-functional requirements are often categorized as :

usability-, reliability, performance, and substitutability-requirements

Need of compliance with any legal and regulatory requirements.

Design constraints due to the operating system used, the platform environment, compatibility issues, or any application standards that apply. Example:

In the Recycling-Machine System, a non-functional requirement that applies to the whole system could be: The machine will allow only one user at a time

Structuring the Use-Case Model To structure the use cases, we have three kinds of

relationships, to factor out pieces of use cases that can be reused in other use cases.

The 3 relashionships are :• include-relationship : a part is factored out and

is explicitly inserted in the base use case, using the include-relationship.

• extend-relationship : a part of a base use case that is optional, or not necessary to understand the primary purpose of the use case

• use cases having commonalties in behavior and structure and similarities in purpose, their common parts (base use case or parent). The child use cases can insert new behavior and modify existing behavior in the structure they inherit from the parent use case.

Structuring the Use-Case Model Internet Customer is a specialization of Customer, indicated with an actor-generalization

”Phone Order ” and ”Internet Order” are both variations of the more general Place Order use case

The Request Catalog use case represents an optional segment of behavior that is not part of the primary purpose of Place Order

Are Use Cases Always Related to Actors? A use case instance is always started by an actor asking

the system to do something, to enforce the system to provide only the functionality that users need, and nothing else .

Exceptions:

– Absctract Use Case (not separately instantiable), its behavior may not include interaction with any actor.

– A child use case in a generalization-relationship does not need to have an actor associated with it if the parent use case describes all actor communication.

– A base use case in an include-relationship does not need to have an actor associated with it if the inclusion use case describes all actor communication.

– A use case may be initiated according to a schedule (for example, once a week or once a day), which means the system clock is the initiator. The system clock is internal to the system - a fictive actor "Time" show how the use case is initiated in your use-case diagrams.

Analysis and Design

Analysis and Design

Purpose To transform the requirements into

a design of the system-to-be. To evolve a robust architecture

for the system. To adapt the design to match the

implementation environment, designing it for performance.

Architecture

The organization or structure of the system's significant components interacting through interfaces, with components composed of successively smaller components and interfaces

Define the Architecture

Purpose

Defining a candidate architecture and constraining the architectural techniques to be used in the system.

It relies on experienced gained in similar systems ( do not waste time in 'architectural rediscovery)

In systems in which there is already a well-defined architecture, architectural analysis may be omitted;

architectural analysis is primarily of benefit when developing new and unprecedented systems.

Architecture analysisPurpose

•Create an initial sketch of the architecture of the system

•Define an initial set of architecturally significant elements to be used as the basis for analysis

•Define an initial set of analysis mechanisms

•Define the initial layering and organization of the system

•Define the use-case realizations to be addressed in the current iteration

•Identify analysis classes from the architecturally significant use cases

•Update the use-case realizations with analysis class interactions

Survey Available Assets • Understand the requirements of the environment for which assets are being

considered.

• Understand the system scope and the general functionality required.

• Search through organizational asset bases, industry literature, to identify assets or similar projects. ( industry models, frameworks, classes, and experience)

• Assess whether available assets could contribute to solving the key challenges of the current project, and are compatible with its constraints.

• Analyze the extent of fit between asset and customer requirements.

• Consider whether any of the requirements are negotiable (to enable use of the asset).

• Assess whether the asset could be modified or extended to satisfy requirements.

• Assess the trade-offs in cost, risk and functionality from adopting the asset.

• Decide in principle whether to use one or more assets, and document the rationale for this decision.

Use case realisationDefinition A use-case realization represents the design perspective of a use case. Group a number of artifacts related to the design of a use case, such as class

diagrams of participating classes and subsystems, and sequence diagrams which illustrate the flow of events of a use case, performed by a set of class and subsystem instances.

Class Diagrams       For each use-case realization there may be one or more class diagrams depicting its participating classes

Collaboration and Sequence Diagrams       

For each use-case realization there is one or more interaction diagrams depicting its participating objects and their interactions. There are two types of interaction diagrams: Sequence diagrams and collaboration diagrams