






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)
1

2







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
3






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
4





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
5



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
6



A use-case model is the complete set of use cases, actors, and their interactions
Five steps to build the Use-Case Model
1.
2.
Identify the describe the actors
Identify the use cases and write a brief description
3.
4.
5.
Identify the actor and use case relationships
Outline the individual use cases
Refine the use cases
7



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?
8



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 Setting
Actor(s): Homeowner/programmer
Description: Homeowner/programmer sets lighting and alarm options for an extended stay away from home
9

 An actor can be involved in several use cases and a use cases can have more than one actor
Program
Vacation Settings
Homeowner/
Programmer
Set
Clock
Change
Password
10



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?
11





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
12

Actor
Homeowner
Programmer
Resident
Description
Operator who programs various features using either optional PC Programmer or the CCU
Emergency
Receiver
Light Bank
Actor that interacts with system on a daily-usage basis
When an emergency signal is activated by a resident, a phone call is made to this actor
Set of light banks grouped together for common action
Wireless remote control device Wireless Remote
Controller
Lumenations
Services
Motion Sensor
A Lumenations service person who access the system remotely for maintenance purposes
Motion senor inputs
13

Lights and other
Note: new actor, Resident turns lights off and on. Homeowner can program the control switch
Resident
Control
Switch
Emergency
Receiver TBD
Central
Control Unit
PC
Programmer
(optional) HOLIS
Homeowner/ programmer
Luminations
Services
14

Resident
Homeowner/ programmer
Turn light on/off
Activate
Scene
Light Banks (1-32)
Activate
Vacation Mode
Indicate
Emergency
Program
Scene
Program Vacation
Sequence
Motion Sensor (1-8)
Initiate Motion
Sequence
Emergency
Receiver
15





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
16

17

 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.
18






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 lowerlevel subsystem
The lowest level is usually comprised of hardware or software only
19



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
20





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
21




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
22

23





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
24



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
25





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
26




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
27





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
28

29



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
30

Emily
VP and GM
Tracy
Director of Engineering
Marcy
Software Development
Manager
Earl
Software Lead
Mark
Architect
Galvin
QA Lead
Test Team
Rick
Director of Marketing
Alyssa
Product Manager
Russ
Software Lead
Louise
Doc Lead
Developers
Gene
Software Lead
31

 Graphical view of major release dates, and milestones for delivery, and other key events
32










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
33





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
34

35

36




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
37