SSD Lecture 4 CS-463 Umair Javed

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)

Session Outline

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

Other Types of Requirements

• Documentation • Packaging • Supportability • Licensing • … etc . (non-functional FURPS categories) 

Supplementary Specification

Glossary

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

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

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

• • • • • • • • • • • • • •

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.)

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?

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”

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

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 Constraints NextGen Example: Page 91

Context Diagram for NextGen

[Larman, 2002]

Impact of Vision Doc, Supplementary Specification, Glossary

[Larman, 2002]

Working with Problem Statement & Vision Document

[Larman, 2002]

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

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

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

Evolution of Use Cases

[Larman, 2002]

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)

SSD for Process Sale

(order follows steps in use case) [Larman, 2002]

Mapping Use Cases to SSDs

[Larman, 2002]

The System Boundary

[Larman, 2002]

Choosing Event and Operation Names

[Larman, 2002]

SSD with Use Case Text

[Larman, 2002]

Impact of SSDs on Other Artifacts

[Larman, 2002]

Questions and Discussion

References

• Craig Larman • SW Engineering for IT Course at CMU

Vision and Scope Document

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

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

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

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

Vision & Scope Document

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

PMan: Vision of the Solution

• Vision Statement – – – – – –

For Who The Is That

our project managers are on travel, and also at the home office PMan application a document access system 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.

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

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

Vision & Scope Document

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

PMan: Scope and Limitations

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

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

Vision & Scope Document

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

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

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

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.

Vision & Scope Document

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