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)
37
Embed
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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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