1. SSD Lecture 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 (7:25)

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 aren’t 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 Stakeholder Descriptions
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 Summary of System Features
Product Perspective
Summary of Benefits
Assumptions and Dependencies
Cost and Pricing
Licensing and Installation
Summary of System Features
Other Requirements and Constraints NextGen Example: Page 91

13. Context Diagram for NextGen
[Larman, 2002]

14. Impact of Vision Doc, Supplementary Specification, Glossary
[Larman, 2002]

15. Working with Problem Statement & 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 follows steps in use case)
[Larman, 2002]

22. Mapping Use Cases to 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 on Other 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 let’s 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 won’t 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.,

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 anyone’s 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 8:00-11:00 am, 4:00-9:00 pm, weekends 10:00-4:00.

45. Vision & Scope Document
Business Requirements
Vision of the Solution
Scope and Limitations
Business Context    