Understanding Requirements

Use Cases:

Requirements In Context

Importance of Requirements Analysis

Challenged projects : projects that did not materialize or were not completed on time

37% of the problems with such projects were related to requirements:– 13% - poor user input– 12% - incomplete requirements– 12% - changing requirements

Types of RequirementsFURPS+

Functional - features, capabilities, security Usability - human factors, help, documentation Reliability - frequency of failure, recoverability,

predictability Performance - response times, throughput,

accuracy, availability, resource usage Supportability - adaptability, maintainability,

configurability

The + in FURPS+

Implementation - resource limitations, language and tools, hardware, etc.

Interface - constraints imposed by interfacing with external systems

Operations - system management in its operational setting

PackagingLegal - licensing and so forth

What artifacts may start in inception? Vision and business case

– Describes high-level goals and constraints. Use Case model

– Describes a set of typical scenarios encountered in using a system. Consists mainly of behaviors (functional requirements).

Supplementary specification– Describes other requirements not in use cases

Consists mainly of non-functional requirements Glossary

– Key domain terminology Data dictionary. Records requirements relating to data, such as

validation rules, acceptable values, etc; can detail any element, e.g. object attribute, parameters, report layout,

etc; Risk list and Risk Management Plan

– Describes business, technical, resource and schedule risks and ideas for their mitigation or response.

What artifacts may start in inception? Prototypes and proof-of-concepts Iteration plan

– Describes what to do in the first elaboration iteration Phase Plan & Software development Plan

– Guess for elaboration phase duration. Tools, people, education and other resources.

Development Case– Description of the customized UP steps and artifacts for

this project. Artifacts will be partially completed in this phase

and will be refined in later iterations.

The Use-Case Model

defined within the requirements discipline it is the set of all use casesa model of the system’s functionality and

environmenthelp keep the system goals and

requirements clear to alleasier – especially for end-users –

contribute meaningfully.

Use Cases reflect the goals of the customers and end users records the story of achieving the goal different levels of use cases concentrate on the goal oriented use case discover the actors scenarios - use case instance set of use case instances where each is a sequence of actions a

system performs that yields an observable result of value to a particular actor

set of use case instances of related success and failure scenarios that describe actors using a system to support a goal.

Use Cases as Requirements

Use cases are requirements – primarily functional – central mechanism for requirement discovery– not all the requirements are described this way– they are text documents not diagrams

UML diagrams describes the use cases, actors and their relationships

Specify what the system does not how it does it

Goals and Scope of a Use Case At what level and scope should use cases be expressed? A: Focus on uses cases at the level of elementary

business process (EBP). EBP: a task performed by one person in one place at

one time which adds measurable business value and leaves the data in a consistent state.– Approve credit order - OK.– Negotiate a supplier contract - not OK.

It is usually useful to create separate “sub” use cases representing subtasks within a base use case.– e.g. Paying by credit

Use Cases and Goals an EBP-level use case is a user-goal use case To find use cases at this level:

– find the user goals– define a use case for each goal

Don’t ask: "How will the system be used?" ask "What are the goals of the users?"– "Login" is not a user goal - therefore not an EBP-

level use case. Place a refill order is a goal Fill out a feedback form is a goal

Use cases and adding value

Actor: something with behavior, such as a person, computer system, or organization, e.g. a cashier.

Scenario: specific sequence of actions and interactions between actors and the system under discussion, e.g. the scenario of successfully purchasing items with cash.

Use case: a collection of related success and failure scenarios that describe actors using a system to support a goal.

Use cases and adding value

Handle returnsMain success scenario: A customer arrives at a checkout

with items to return. The cashier uses the POS system to record each returned item…

Alternate scenarios:If the credit authorization is reject, inform customer and

ask for an alternative payment method.If item identifier not found in the system, notify the

Cashier and suggest manual entry of the identifier code.…

Use case types and formats

Black-box use cases describe system responsibilities, i.e. define what the system must do.

Uses cases may be written in three formality types– Brief: one-paragraph summary, usually of the main

success scenario.– Casual: Informal paragraph format (e.g. Handle returns)– Fully dressed: elaborate. All steps and variations are

written in detail.

Primary Actors, Goals and Use Cases

Use Cases are define to satisfy the goals of the primary actors - the principal actor that calls upon the system to fulfill a goal

The basic procedure is:– choose the system boundary– identify the primary actors– identify their goals at the highest EBP level– define the use cases that satisfy the user goals

Choosing the System Boundary

Defining the boundary of the system can be done by defining what is outside the system

Finding Primary Actors and Goals

Primary vs. supporting actorsBrainstorminggoals reveal actors; actors reveal goalsSome questions to ask:

– Who starts and stops the system?– Who does user and security management?– Who does system administration?– Who evaluates system performance? logs? – How are software updates to be handled? Pull or push?– Is time an actor?

Actor - Goal ListCustomer add request

delete request

change request

list prescriptions

Administrator add user

delete user

modify user

manage security

Prescription Activity System analyze prescription data

Manager start up system

shut down system

Events, Actors, Goals

External Event From Actor Goal Achieved

enter sale line item cashier process a sale

enter payment cashier or customer

process a sale

Actors

Primary actor - has user goals fulfilled through using services to the system under development (SuD)– Why identify - to find user goals

cashier in a POS customer of Pharmacy

Supporting Actor - provides a service to the SuD – Why identify - to clarify external interface

Offstage Actor - has an interest in the SuD - a gov't tax agency– Why identify - to ensure that all necessary interests are identified

Fully-dressed example:Process Sale

Use case UC1: Process SalePrimary Actor: CashierStakeholders and Interests:

-Cashier: Wants accurate and fast entry, no payment errors, …-Salesperson: Wants sales commissions updated.…

Preconditions: Cashier is identified and authenticated.Success Guarantee (Postconditions):

-Sale is saved. Tax correctly calculated.…

Main success scenario (or basic flow): [see next slide]Extensions (or alternative flows): [see next slide]Special requirements: Touch screen UI, …Technology and Data Variations List:

-Identifier entered by bar code scanner,…Open issues: What are the tax law variations? …

Main success scenario (or basic flow): The Customer arrives at a POS checkout with items to purchase.The cashier records the identifier for each item. If there is more thanone of the same item, the Cashier can enter the quantity as well.The system determines the item price and adds the item information tothe running sales transaction. The description and the price of the currentitem are presented.On completion of item entry, the Cashier indicates to the POS system that item entry is complete.The System calculates and presents the sale total.The Cashier tells the customer the total.The Customer gives a cash payment (“cash tendered”) possibly greaterthan the sale total.

Extensions (or alternative flows):If invalid identifier entered. Indicate error.If customer didn’t have enough cash, cancel sales transaction.

Fully dressed example:Process Sale (cont.)

Essential vs. Concrete style

Essential: Focus is on intend.– Avoid making UI decisions

Concrete: UI decisions are embedded in the use case text.– e.g. “Admin enters ID and password in the

dialog box (see picture X)”– Concrete style not suitable during early

requirements analysis work.

Use Case Diagrams

NextGen

Cashier Handle returnsPayment

AuthorizationServiceProcess Rental

<<actor>>Tax Calculator

Primary actors tothe left: have user goals.

Supporting actors tothe right: they providea service.

Alternative notation forcomputer system actor

Process Sale