SSD Lecture 4

1
SSDLecture 4

• CS-463
• Umair Javed

2
Agenda

• Assignment 1 in
• Usecase Diagram. Impact of Usecase doc on other
  docs
• System Behavior (SSD)
• SSD (Withdraw Cash)-In class exercise
• Ideas about usecase design of project
• Some structure of FS (Usecase Screens Screen
  DD SSD)
• VSS
• Rational Rose
• Meeting with Shahab (725)

3
Session Outline

• Identifying Other Requirements
• Supplementary Specification, Glossary, Vision
• System Features, Quality Attributes
• From Inception to Elaboration
• System Sequence Diagrams
• Identify System Events
• From Use Cases to Sequence Diagrams

4
Other Types of Requirements

• Documentation
• Packaging
• Supportability
• Licensing
• etc. (non-functional FURPS categories)?
  Supplementary Specification

5
Glossary

• Terms and Definitions
• Data Dictionary
• Define important data objects and their
  attributes (products, etc.)

6
Vision Document

• Summarize the important ideas
• Why the project was proposed
• What the problems are to be solved
• Identify stakeholders, goals
• Vision of proposed solution
• Outline of core requirements
• Example Task 1 description stakeholder meeting
  minutes

7
Supplementary Spec NextGen Example (p. 84)

• Revision History
• Introduction
• Functionality
• Usability
• Reliability
• Performance
• Supportability
• Constraints
• Purchased Components

• Open Source Components
• Interfaces
• Business Rules
• Legal Issues
• Domain Information

8
Supplemental Requirements

• FURPS
• Reports
• Hardware and Software Constraints
• Process/tool constraints
• Design/implementation constraints
• Internationalization concerns
• Documentation (user, install, admin, )
• Licensing other legal concerns
• Packaging
• Standards (technical, safety, quality)
• Physical environment (heat, vibration, )
• Operational concerns (errors, backups, )
• Domain or business rules
• Domain information (entities, business processes,
  etc.)

9
Requirements vs. Constraints

• Constraints arent behaviors
• Constraints are a limitation or restriction
  (e.g., must)
• Must use Oracle
• Must run on Linux
• Beware early design decisions masquerading as
  constraints
• Question Is this constraint unavoidable?

10
Quality Attributes

• Values not necessarily high(e.g., low
  supportability okay in a temporary product)
• Two types
• Observable a run-time(usability, performance, )
• Not observable at run-time(supportability,
  testability, )
• Trade-offs
• E.g., highly fault-tolerant vs. easy to test

11
Vision Document

• Positioning
• Business Opportunity
• Problem Statement
• Product Position Statement
• Alternatives and Competition
• Stakeholder Descriptions
• Market demographics
• Non-user stakeholders
• Key high-level goals/problems

12
Vision Document 2

• Product Overview
• Product Perspective
• Summary of Benefits
• Assumptions and Dependencies
• Cost and Pricing
• Licensing and Installation
• Summary of System Features
• Other Requirements and ConstraintsNextGen
  Example Page 91

13
Context Diagram for NextGen
Larman, 2002
14
Impact of Vision Doc,Supplementary
Specification,Glossary
Larman, 2002
15
Working with ProblemStatement Vision Document
Larman, 2002
16
Elaboration

• Majority of requirements are discovered and
  stabilized
• Major risks are mitigated or retired
• Core architecture implemented
• Production subset architectural baseline
• Commonly, 2-4 timeboxed iterations

17
Architecture

• Designing at the seams
• Identify processes, layers, packages, subsystems
  and high-level interfaces
• Partial implementation to clarify the interfaces
  and responsibilities
• Refine intermodule remote interfaces
• Integrate existing components
• Test by implementing end-to-end scenarios

18
Planning an Iteration

• Requirements, iterations ranked by
• Risk (technical complexity, )What risks does
  this iteration address?
• Coverage (functional modules, )Consider all
  major components early
• Criticality (functions of high biz
  value)Emphasize critical functions

19
Evolution of Use Cases
Larman, 2002
20
System Behavior

• Describe what a system does without explaining
  how
• Use cases, sequence diagrams, contracts
• System Sequence Diagram (SSD) events generated
  by external actors, inter-system events, and
  their ordering(not detailed method calls between
  objects)

21
SSD for Process Sale
TIME
(order followssteps in use case)
Larman, 2002
22
Mapping Use Casesto SSDs
Larman, 2002
23
The System Boundary
Larman, 2002
24
Choosing Event and Operation Names
Larman, 2002
25
SSD with Use Case Text
Larman, 2002
26
Impact of SSDs onOther Artifacts
Larman, 2002
Larman, 2002
27
Questions and Discussion
28
References

• Craig Larman
• SW Engineering for IT Course at CMU

29
Vision and Scope Document
30
Case Study Project Management Software Project
(PMan)

• Company X has project managers who are always on
  the road
• Project documents are thus often unavailable to
  managers, causing delays and lost business
• Project documents are often out of date, making
  oversight difficult

31
Vision Scope Document

• Business Requirements
• Background
• Business Opportunity
• Business Objectives Success Criteria
• Customer or Market Needs
• Business Risks
• Vision of the Solution
• Scope and Limitations
• Business Context

32
PMan Business Requirements

• Background
• We have project managers who are always on the
  road
• Project documents are thus often unavailable to
  managers, causing delays and lost business
• Project documents are often out of date, making
  oversight difficult
• Business Opportunity
• Internet connectivity is everywhere, so lets use
  it
• A Web-based system providing access to project
  documents
• Allow read, edit, addition, with privilege
  restrictions
• No inexpensive equivalent commercial product
• We have lots of folks who can build this during
  idle time

33
PMan Business Requirements

• Objectives Success Criteria
• Reduce calls to home office to fax project
  documents by 75
• Reduce home office support costs by 15
• Reduce customer service complaints by 35
• Customer/Market Needs
• Reduce by 75 the amount of stuff project
  managers need to carry on the road, without loss
  of effectiveness
• Business Risks
• A home-grown solution will take so long that it
  wont be cost effective vs. a commercial solution
• We may not think of product details that are most
  effective

34
Vision Scope Document

• Business Requirements
• Vision of the Solution
• Vision Statement
• Major Features
• Assumptions Dependencies
• Scope and Limitations
• Business Context

?
35
PMan Vision of the Solution

• Vision Statement
• For our project managers
• Who are on travel, and also at the home office
• The PMan application
• Is a document access system
• That permits viewing and updating project files,
  that is
• Unlike existing manual methods and existing
  affordable commercial systems.
• Our product gives project managers the ability to
  access all project-related document while on
  travel, eliminating the need for home office
  support for lookup, faxing and updating.

36
PMan Vision of the Solution

• Major Features
• Secure login
• Allow editing of project documents
• Allow editing of personnel assignments
• Allow communication with other project managers
• Allow entry of new projects, including client
  info, project requirements, cost projections,
  profit opportunities

37
PMan Vision of the Solution

• Assumptions Dependencies
• All of our project managers have Web access while
  on the road
• The PMan system can successfully access and
  integrate with the home-office information
  systems
• Our home-office IT people are capable of
  supporting any new technologies we use

38
Vision Scope Document

• Business Requirements
• Vision of the Solution
• Scope and Limitations
• Scope of Initial Release
• Scope of Subsequent Releases
• Limitations Exclusions
• Business Context

?
?
39
PMan Scope and Limitations

• Scope of initial release
• Focus on reading/modifying existing project
  documents
• Time stamps, version control
• Very simple menu-based interface

40
PMan Scope and Limitations

• Scope of subsequent releases
• Improve interface
• Add capability to originate new projects
• Add user privilege functionality
• Allow personnel assignments
• Limitations and exclusions
• The system will be coupled with the home office
  database only
• The system will not replace any existing
  communication modes, e.g., email

41
Vision Scope Document
?

• Business Requirements
• Vision of the Solution
• Scope and Limitations
• Business Context
• Stakeholder Profiles
• Project Priorities
• Operating Environment

?
?
42
PMan Business Context

• Stakeholder Profiles
• Project managers
• Benefits include improved access to project
  information, communication of project details
  with other personnel, faster interaction with
  clients
• Likely to quickly embrace system
• Senior management
• Clients
• Home office personnel

43
PMan Business Context

• Project priorities
• Releases as described in the scope
• Use our own programmers, but initially only when
  they have no other project duties. If the system
  appears successful, assign more programmer time,
  but no more than 10 of anyones time

44
PMan Business Context

• Operating environment
• The system is based on Internet connectivity
• Assume project managers will have adequate
  wireless/wired Internet access
• Managers must be able to download 10-page MS Word
  document in less than 1 minute at 56K
• System must be available weekdays 800-1100 am,
  400-900 pm, weekends 1000-400.

45
Vision Scope Document

• Business Requirements
• Vision of the Solution
• Scope and Limitations
• Business Context

?
?
?
?