VISION STATEMENT WHAT IS A VISION STATEMENT The

VISION STATEMENT

WHAT IS A VISION STATEMENT The vision statement should reflect a balanced view that will satisfy the need of diverse customers. idealistic but should be grounded in the realities of existing or anticipated customer markets, enterprise architectures, organizational strategic directions, and resource limitations.

EXAMPLE – VISION STATEMENT (CHEMICAL TRACKING SYSTEM) The chemical tracking system will allow scientists to request containers of chemicals to be supplied by chemical stockroom or by vendors. The location of every chemical container within the company, the quantity of the material remaining in it, and the complete history of each container’s location and usage will be known by the system at all times. The company will save 25% on chemical costs by fully exploiting chemicals already available within the company, by disposing of fewer partially used or expired containers, and by using a standard chemical purchasing process. The chemical tracking system will also generate all reports required to comply with federal and state government regulations that require the reporting of chemical usage, storage, and disposal.

ASSUMPTION AND DEPENDENCIES All assumptions that were made when conceiving the project have to be recorded.

EXAMPLE the management sponsor for the chemical tracking system assumed that Chemical Tracking System would replace the existing chemical stockroom inventory system and interface to the appropriate purchasing department applications

SCOPE Defines Concept and limitations boundary range of the proposed solution identify certain capabilities Clarifying stakeholder’s that the product will not include. expectations. . Propose requirements That are included Excluded as beyond scope Optional as there is a way for where in future accommodating them some

CONTEXT DIAGRAM Illustrate boundary laid by scope Shows connections between System being developed Problem being addressed Outside world Identifies Entities outside the system that are governing the actions Flow of data between entity and system Can be part of SRS or Data Flow Modeling

CONTEXT DIAGRAM

USE CASES

USE CASE MODELS An increasingly popular technique for eliciting requirements Express functional requirements in terms of WHAT the system should do Can be used in both traditional and object-oriented projects Can also provide a foundation for system verification

COMPONENTS ACTORS describe things that exist outside the system and interact with the system --- they represent roles that individuals, devices, other systems can play when interacting with the system A USE-CASE is a specific interaction between an actor and the system that represents a way of using the system --- a use-cases represent WHAT actors do with the system A USE-CASE MODEL consists of the description of all the ACTORS & USECASEs or a system The set of all possible use-cases for a system represent the complete functionality from the user perspective

NAMING USE CASES Actor-->Action-->Subject e. g. , Customer applies for Loan Actor is the actor that triggers/initiates the use Action-->Subject e. g. , Apply for Loan Initiating actor is not specified in name

HOW TO FIND USE CASES Choose the system boundary Identify the primary actors Identify goals for each actor Define use cases that satisfy goals

USE CASE MODELING STEPS Identify actors Define high-level use cases for all system requirements Document use cases Prioritize all use cases Allocate use cases to project iterations/increments/releases Develop expanded use cases during each development iteration/increment/release

USE CASE BASIC DIVISION High level format Brief 2 -3 sentences Useful in inception phase Terse and vague on design decisions Expanded format Detail and fully dressed Step by step events Only few are written in one iteration – elaboration phase

IDENTIFICATION OF USE CASE Actor Based Identify actors For each actor identify the processes they initiate or participate in Event Based Identify external events that a system must respond to Relate events to actors and use cases

CONTENTS OF HIGH LEVEL FORMAT Use Case: Name of the use case Actors: external or internal Description: basic description in 3 -4 lines

EXAMPLE Use Case: Startup Actors: Manager Description: A manager powers on POST in order to prepare it for use by cashiers. The Manager validates that the date and time are correct, after which the system is ready for cashier use

FULLY DRESSED FORMAT (EXPANDED FORMAT) Use case name Primary Actor Overview Preconditions Success Guarantee Typical Course of Events Alternative course of events

DETAILS… Use case name Start with a verb “Process Sale” Primary actor Calls on the system to delivery the service “Cashier” Success Guarantee What must be true on successful completions, and worth telling the reader “Sales is saved. Tax is correctly calculated…

DETAILS… Typical Course of Events(or Basic flow) A typical, unconditional happy path scenario of success Record steps: An interaction between actors A validation (usually by the system) A state change by the system E. g. 1. Customer arrives at a POS checkout 2. Cashiers starts a new sale 3. Cashier enters item identifier 4. System record sales line item… Cashier repeats steps 3 -4 until indicated done. 5. System presents total with taxes calculated 6. …

DETAILS… Alternate scenarios of success or failure Scenario branches (success/failure) Longer/more complex than basic flow Branches indicated by letter following basic Two parts: condition, handling flow step number, e. g. “ 3 a” E. g. Extensions: When possible write the condition as something that can be detected 5 a: System can not communication with external tax calculation system 5 a: External tax calculation system not working If condition can arise within a range of steps 3 a. Invalid identifier 1. System signals error and reject entry 3 -6 a: customer asks Cashier to remove an item from the purchase 1. Cashier enters the item identifier for removal from the sale 2. System displays updated running total. At the end of extension handling, by default the scenario merges back with the main success scenario, unless the extension indicates otherwise

CHOOSE THE SYSTEM BOUNDARY In the case study, the POS system itself is the system under design; Everything outside of it is outside the system boundary Identify what is outside would help to identify the boundary

FIND PRIMARY ACTOR AND GOALS Questions to help find actors and goals Is “time” an actor because the system does something in response to a time event? In addition to human primary actors, are there any external software or robotic systems that call upon services of the system?

ACTORS, GOAL AND BOUNDARIES

VALID OR USEFUL USE CASES Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log. In Move Piece on Game Board All are valid, but at different level; better question is “what is a useful level to express use cases”

GUIDELINES…. TESTS What tests can help find useful use cases? Boss Test Log in does not sounds like something that will make your boss happy The EBP Test Elementary Business Process “A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent states, e. g. Approved Credit or Price Order. The Size Test A use case is very seldom a single action or step

APPLYING TESTS Negotiate a Supplier Contract Much Handle returns Ok with the boss. Seems like an EBP. Size is good Log In Not broader and longer than an EBP OK with the boss, no measurable business value Move Piece on Game Board Single step – fail the size test Reasonable violations of the tests It is sometimes useful to write separate sub functionlevel use cases representing subtasks or steps within a regular EBP-level use case.

APPLYING UML – USE CASE DIAGRAM

DIAGRAM NOTATION

RELATIONSHIP AMONG USE CASES Use cases can be reused and extended in two different fashions: extends and uses “uses” relationship one use case invokes the steps defined in another use case during the course of its own execution. is similar to a relationship between two functions where one makes a call to the other function “extends” relationship kind of a generalization- specialization relationship. In this case a special instance of an already existing use case is created. The new use case inherits all the properties of the existing use case, including its actors.

USES RELATIONSHIP

EXTENDS RELATIONSHIP

EXTENDED ACTOR

ACTIVITY DIAGRAM Activity diagrams give a pictorial description of the use case. It is similar to a flow chart and shows a flow from activity to activity. It expresses the dynamic aspect of the system.

LIMITATIONS OF USE CASES

Non Functional requirements are not recorded Usability Color blind people Reliability 24/7 operation Portability Windows and Solaris run able Performance X operation be completed in 1 sec 90% of time Accessible over internet Describe system as black box from user’s perspective

CREDITS Craig Larman, Applying UML and Patterns 2 nd Edition Roger S. Pressman, Software Engineering – A practitioner’s Approach 6 th Edition Lecture Slide, Dr. Fakhar Lodhi VU CS 504 Derek Coleman, A use case template, Draft for discussion Lecture Slides, Joseph M. Demasco, Johns Hopkins University, Course 605. 704