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 (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. Revision History Introduction Functionality Usability Reliability Performance Supportability Constraints Purchased Components Open Source Components Interfaces Business Rules Legal Issues Domain Information Supplementary Spec: NextGen Example (p. 84)

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 • 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 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., 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 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    