Text Layout - PowerPoint PPT Presentation

1 / 35
About This Presentation
Title:

Text Layout

Description:

... system works for the actor ... Will the actor create, store, change, remove, or read ... signal is activated by a resident, a phone call is made to this actor ... – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Slides: 36
Provided by: ba22
Category:
Tags: actor | layout | text

less

Transcript and Presenter's Notes

Title: Text Layout


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 from 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
  • Identify and describe the actors
  • Identify the use cases and write a brief
    description
  • Identify the actor and use case relationships
  • Outline the individual use cases
  • 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 Setting Actor(s) Homeowner/prog
rammer Description Homeowner/programmer sets lig
hting 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
    use cases can have more than one actor

Program Vacation Settings
Set Clock
Homeowner/ Programmer
Change Password
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 Actors
14
HOLIS with subsystem and actors
Note new actor, Resident turns lights off and
on. Homeowner can program the control switch
Lights and other
Resident
Control Switch
Emergency Receiver TBD
Central Control Unit
PC Programmer (optional)
Luminations Services
HOLIS
Homeowner/ programmer
15
Portion of HOLIS Use-Case Model
Turn light on/off
Motion Sensor (1-8)
Light Banks (1-32)
Activate Scene
Resident
Initiate Motion Sequence
Activate Vacation Mode
Indicate Emergency
Program Scene
Emergency Receiver
Program Vacation Sequence
Homeowner/ programmer
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 Information
  • Chapter 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
    productsno 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 results 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 document
  • Develop a set of use cases that 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 defines 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 projects 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 projects 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 Team
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 likeavailable
    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
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
Write a Comment
User Comments (0)
About PowerShow.com