1

Text Layout

Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder

Needs (8-13) Team Skill 3 – Defining the System (14-17) Team Skill 4 – Managing Scope (18-19) Team Skill 5 – Refining the System Definition ( 20-24) Team Skill 6 – Building the Right System (25-31)

2

A Use Case Primer

Chapter 14

3

Benefits of Use Cases Force developers to think through the problem from the

user perspective Give context for the requirements Provides an ordering mechanism for requirements Reduce the risk of transitioning form an expression of

requirements to a differing implementation Carry over directly into the testing process Serve as inputs into user documentation

4

Definition A use case describes sequences of actions a system

performs that yield an observable result of value to a particular actor

Sequences of actions – an action is atomic; it is performed either entirely or not at all

System performs – system works for the actor An observable result of value – the use case must be of

value to the user A particular actor – The actor initiates the use case

Use Case

5

Actors An actor is someone or something that interacts with the

system Users

Homeowners are actors on HOLIS system Authors are actors on a word processing system

Other systems or applications HOLIS Control Switch is an actor on the HOLIS Central Control

Unit

A device Lights Printer

Actor

6

Use Case Anatomy Mandatory elements

Name – Unique and descriptive Brief description – Paragraph describing purpose Actors – List all actors that interact with this use case Flow of events – Basic flow and Alternate flows

Optional elements Pre-conditions – conditions that must be present in order for a

use case to start Post-condition – state of the system after a use case has run its

course System or subsystem – level of use case. System causes

multiple subsystems to interact Other stakeholder – non users Special requirements – performance or throughput

7

Building a Use-Case Model A use-case model is the complete set of use cases,

actors, and their interactions Five steps to build the Use-Case Model

1. Identify the describe the actors

2. Identify the use cases and write a brief description

3. Identify the actor and use case relationships

4. Outline the individual use cases

5. Refine the use cases

8

Actors Discussed in Chapter 7 – dividing the world into two

classes, the system and things that interact with the system

Questions to consider Who uses the system? Who gets information from this system? Who provides information to the systems? Where in the company is the system used? Who supports and maintains the system? What other systems use this system?

9

Identify the Use Cases Questions to consider

What will the actor use the system for? Will the actor create, store, change, remove, or read data in the

system? Will the actor need to inform the system about external events

or changes? Will the actor need to be informed about certain occurrences in

the system?

Provide a brief description that elaborates the intent of the use case

Program Vacation SettingActor(s): Homeowner/programmerDescription: Homeowner/programmer sets lighting and alarm options for an extended stay away from home

10

Identify the Actor – Use-Case Relationships An actor can be involved in several use cases and a use

cases can have more than one actor

Homeowner/Programmer

ProgramVacation Settings

SetClock

ChangePassword

11

Outline the Use Cases Outline all the basic flows first

Basic flow is the most common path What event starts the use case? How does the use case end? How does the use case repeat some behavior?

Outline alternate flows Are there optional situations? What odd cases might happen? What variants might happen? What may go wrong? What may not happen? What kind of resources can be blocked?

12

Refining the Use Cases At a later point in time, analyze the use cases Look for more alternative flows including exception

conditions Add pre and post conditions – make sure the use cases

still are what was intended with the post conditions Some experts believe on writing the pre and post

conditions during step 4 and not in refinement

13

HOLIS ActorsActor Description

Homeowner

Programmer

Operator who programs various features using either optional PC Programmer or the CCU

Resident Actor that interacts with system on a daily-usage basis

Emergency Receiver

When an emergency signal is activated by a resident, a phone call is made to this actor

Light Bank Set of light banks grouped together for common action

Wireless Remote Controller

Wireless remote control device

Lumenations Services

A Lumenations service person who access the system remotely for maintenance purposes

Motion Sensor Motion senor inputs

14

HOLIS with subsystem and actors

Homeowner/programmer

LuminationsServices

Emergency Receiver TBD

Lights and other

Resident

Control Switch Central

Control Unit

PCProgrammer

(optional) HOLIS

Note: new actor, Resident turns lights off and on. Homeowner can program the control switch

15

Portion of HOLIS Use-Case Model

Homeowner/programmer

Emergency Receiver

Light Banks (1-32)

Resident

Turn light on/off

ActivateScene

ActivateVacation Mode

IndicateEmergency

ProgramScene

Program VacationSequence

Initiate MotionSequence

Motion Sensor (1-8)

16

Key Points Use cases carry the majority of the requirements for the

system The development team, with user involvement, writes the

use cases Use cases are built on a common, standard format Use cases later drive test case development

17

Organizing Requirements InformationChapter 15

18

Systems Requirements Document(s) Reasons why one document may not be adequate

System may be complex and volume of documentation may be excessive

System may be a member of a family of related products…no one document contains all the specs

System may be a subsystem of a larger system and may satisfy only a subset of the requirements

Marketing and business goals need to be separated from product requirements

Other requirements, regulatory or legal, may be imposed on the system and documented elsewhere.

19

Complex Hardware and Software Systems A system-level requirements set is created describing

the system as a whole no reference to any subsystems

Requirements are developed for each subsystem No reference to any lower level subsystem

The resuls are a hierarchy of requirements Requirements are allocated to the appropriate lower-

level subsystem The lowest level is usually comprised of hardware or

software only

20

Product Families A set of closely related products that have much

functionality in common, yet each product contains some unique features

Organize requirements as follows: Develop a product-family vision documents Develop a set of use cases show how users interact with

various applications running together Develop a common software requirements set For each product, develop a vision document, supplementary

specification, and use-case model that dines its specific functionality

21

HOLIS Case Study Vision document for short and longer term visions for

HOLIS, including basic system-level requirements System-level use-case model records use cases and the

actors Hardware requirements specification for the 3

subsystems (control switch, central control unit, and PC programmer)

A supplementary specification for each of the subsystems and a use-case model for how each subsystem interacts with its various actors

22

Key Points

For nontrivial applications, requirements must be captured and recorded in a document, database, model or tool

Different types of project require different requirements organization techniques

Complex systems require that requirements sets be developed for each subsystem

23

The Vision Document

Chapter 16

24

Vision Document Short, well crafted, document capturing…

the project’s objective the needs of the user the features of the system other common requirements

A basis for discussion and agreement among… Marketing and product management team Project team Management team

Similar to a project charter from PMI Similar to SOW in Industry

25

Sample Vision Document Outline – pg 175 1. Introduction

1.1 Purpose of the Vision Document 1.2 Product Overview 1.3 References

2. User Description 2.1 User/Market Demographics 2.2 User Profiles 2.3 User Environment 2.4 Key User Needs 2.5 Alternatives and Competition

26

Sample Vision Document Outline – pg 175 3. Product Overview

3.1 Product Perspective 3.2 Product Position Statement 3.3 Summary of Capabilities 3.4 Assumptions and Dependencies 3.5 Cost and Pricing

4. Feature Attributes 5. Product Features 6. Exemplary Use Cases

27

Sample Vision Document Outline – pg 175 7. Other Product Requirements

7.1 Applicable Standards 7.2 System Requirements 7.3 Licensing, Security, and Installation 7.4 Performance Requirements

8. Documentation Requirements 8.1 User Manual 8.2 Online Help 8.3 Installation Guides, Configuration, and Read Me Files 8.4 Labeling and Packaging

9. Glossary

28

Key Points Every software project will benefit from having a Vision

document The Vision document describes the application in

general terms, including descriptions of the target market, the system users, and the application features

The Vision document defines, at a high level of abstractions, both the problem and the solution

The Delta Vision document focuses on what has changed

29

Product Management

Chapter 17

30

Product Champion Also called – product manager, project manager, IT manager,

project lead, engineering manager, etc. The Champion must…

Manage the elicitation process and determine when enough requirements are discovered

Manage the conflicting inputs Make the trade-offs Own the product vision and advocate for the product Defend against feature creep Maintain a “healthy tension” between what the customer desires and

what the team can deliver Manage expectations of customers and management Communicate features to all stakeholders Manage changing priorities Review use cases and requirements to ensure they conform to the

Vision document

31

HOLIS Software Development TeamEmily

VP and GM

TracyDirector of Engineering

RickDirector of Marketing

AlyssaProduct Manager

MarcySoftware Development

Manager

MarkArchitect

GalvinQA Lead

GeneSoftware Lead

EarlSoftware Lead

RussSoftware Lead

Developers

Test Team

LouiseDoc Lead

32

Product Road Map Graphical view of major release dates, and milestones for delivery,

and other key events

33

Product Manager in a Software Product Company Driving the Vision Maintaining the Product Road Map Defining the Whole Product Plan

Including ancillaries like…available configurations, special hardware, secure access, licensing provisions, etc.

Sponsoring the Use-Case Model and Supplementary Requirements Testing the Product Concept Completing the User Experience

User documentation, online help, tool tips, etc. Defining Commercial Terms

Licensing Pricing Policy Customer Support

Positioning and Messaging Supporting Activities

Branding and Product Labeling End User Training Product Demo Sales and Marketing

34

Product Champion in an IS/IT Shop Customers work with you and will be around No marketing department Your management may be your customer Still need a product champion and still need to collect

and manage requirements

35

36

37

Key Points Every project needs an individual champion or a small

champion team to advocate for the product In a software products company, the product manager

plays the role of the champion The product manager drives the whole product solution:

the application itself, support, user conveniences, documentation, and the relevant commercial factors