DOC PREVIEW
DREXEL CS 451 - Specifying Requirements with Use Case Diagrams

This preview shows page 1-2-3-20-21-22-41-42-43 out of 43 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 43 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide Number 1OutlineWhere are we?Source of RequirementsRequirements vs. DesignTypes of RequirementsUse CasesUse Case Diagram ObjectiveWhat Makes Good Use-Case Specification?Use Cases as Means of CommunicationOutlineA Simple ExampleFinding ActorsActors can be generalizedLinking Use-CasesUse-Case LevelsThe “Include” ConstructExtend – Graphical RepresentationExample: Amazon Example – cont’dGeneralization between Use-CasesGeneralization HazardsExample: Phone Company Operational SystemExample: Cell Company SystemOutlineStructure of a Use Case SpecificationPreconditionsMain ScenarioGuidelines for Effective WritingSubflow – cont’dUse-Cases – Common MistakesAlternative FlowsAlternative Flows - ExampleWriting IncludeWriting ExtendOutlineHow to Model?How to Model – cont’dCombining ProcessesDividing ProcessesMore GuidelinesWhen Are we Done?Summary1 Spring 2005 Specification and Analysis of Information Systems Specifying Requirements with Use Case Diagrams2 Outline • Introduction • Use Case Diagrams • Writing Use Cases • Guidelines for Effective Use Cases3 Where are we? Phase Actions Outcome Initiation Raising a business need Business documents Requirements Interviewing stakeholders, exploring the system environment Organized documentation Specification Analyze the engineering aspect of the system, building system concepts Formal specification Design Define architecture, components, data types, algorithms Formal Specification Implementation Program, build, unit-testing, integrate, documentation Testable system Testing & Integration Integrate all components, verification, validation, installation, guidance Testing results, Working sys Maintenance Bug fixes, modifications, adaptation System versions Introduction | Diagrams | Writing | Guidelines4 Source of Requirements • Initial requirements come from the customer, by: – Documents, Meetings, reports • Advanced requirements come from the analysts, after studying: – Scope and price – Feasibility (technological, organizational etc) – Prototypes • Final requirements are stabilized in an iterative process. Introduction | Diagrams | Writing | Guidelines5 Requirements vs. Design • Requirements: – What the system should do – More abstract • Design: – How the system should do it – More detailed Introduction | Diagrams | Writing | Guidelines6 Types of Requirements • Visible Functional Requirements – “The system will deliver cash to the customer” – “Cash will be delivered after card was taken out” • Qualitative Requirements – “The authorization process will take no more than 1 sec” • Hidden Requirements – “Database maintenance processes will occur every night” Qualitative Requirements Hidden Functional Requirements Functional Visible Requirements Introduction | Diagrams | Writing | Guidelines7 Illustration Use Cases • A use case is a contract of an interaction between the system and an actor. • A full use-case model comprise of: – A diagram, describing relations between use-cases and actors. – A document describing the use case in details Register User Use case in diagram Use Case in script admin Introduction | Diagrams | Writing | Guidelines8 Use Case Diagram Objective 1. Create a semi-formal model of the functional requirements 2. Analyze and define: – Scope – External interfaces – Scenarios and reactions Introduction | Diagrams | Writing | Guidelines9 What Makes Good Use-Case Specification? • Lack of ambiguity – Each requirement must be interpreted in a single manner. • Completeness – The collection of all use cases is everything that can be done to/with the system. • Consistency – Requirements should not conflict with each other. If there are, tradeoffs must be detected and discussed. • Avoid design – Requirements should raise a need, not answer it. Introduction | Diagrams | Writing | Guidelines10 Use Cases as Means of Communication The use case should stimulate a discussion about what the system should do, mainly with people who are outside of the development team. Introduction | Diagrams | Writing | Guidelines Customers Designers Users11 Outline • Introduction • Use Case Diagrams • Writing Use Cases • Guidelines for Effective Use Cases12 Example A Simple Example Handle MessageCellular PhoneCustomer Bill Management Handle CallExternal PhoneCompanyActors Use Case System boundary Introduction | Diagrams | Writing | Guidelines Association13 Finding Actors • External objects that produce/consume data: – Must serve as sources and destinations for data – Must be external to the system Humans Machines External systems Sensors Organizational Units Introduction | Diagrams | Writing | Guidelines14 Example Actors can be generalized The child actor inherits all use-cases associations Introduction | Diagrams | Writing | Guidelines Should be used if (and only if), the specific actor has more responsibility than the generalized one (i.e., associated with more use-cases) Register ClientSales PersonInstitutional Sales Person Perform Sale Perform Business SaleSales Manager Cancel Sale15 Linking Use-Cases • Linking enables flexibility in requirements specification – Isolating functionality – Enabling functionality sharing – Breaking functionality into manageable chunks • Three mechanism are used: – Include – Extend – Inheritance Introduction | Diagrams | Writing | Guidelines16 Use-Case Levels User goals Perform Sale Choose Products Fill-in billing info Sub-functionality Introduction | Diagrams | Writing | Guidelines Base Use Case: Used directly by the user Alistair Cockburn “Writing Effective Use Cases”17 The “Include” Construct • Include is used when: – Decomposing complicated behavior – Centralizing common behavior • The base use case explicitly incorporates the behavior of another use case at a location specified in the base. Introduction | Diagrams | Writing | Guidelines Perform Sale Fill-in billing info <<include>> Example18 Extend – Graphical Representation • The base use case can incorporate another use case at certain points, called extension points. • Note the direction of the arrow – The base use-case does not know which use-case extends it Introduction | Diagrams | Writing | Guidelines Perform Sale After checkout Gift wrap Products <<extend>> Product is a gift Example19 Example: Amazon Product Page Review Writing Shopping Cart Introduction | Diagrams | Writing


View Full Document

DREXEL CS 451 - Specifying Requirements with Use Case Diagrams

Download Specifying Requirements with Use Case Diagrams
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Specifying Requirements with Use Case Diagrams and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Specifying Requirements with Use Case Diagrams 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?