ssd lecture 4 cs-463 umair javed. agenda assignment 1 in usecase diagram. impact of usecase doc on...
Post on 21-Dec-2015
214 views
TRANSCRIPT
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 Outline1. 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
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
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)
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 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.
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.