Vision Statement

1. Vision Statement

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

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

4. Assumption and Dependencies All assumptions that were made when conceiving the project have to be recorded.

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

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

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

8. Context Diagram

9. USE CASES

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

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

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

13. How to find Use Cases • Choose the system boundary • Identify the primary actors • Identify goals for each actor • Define use cases that satisfy goals

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

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

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

17. Contents of High Level Format • Use Case: • Name of the use case • Actors: • external or internal • Description: • basic description in 3-4 lines

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

19. Fully Dressed Format (Expanded Format) • Use case name • Primary Actor • Overview • Preconditions • Success Guarantee • Typical Course of Events • Alternative course of events

20. 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…

21. 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. …

22. Details… • Alternate scenarios of success or failure • Scenario branches (success/failure) • Longer/more complex than basic flow • Branches indicated by letter following basic flow step number, e.g. “3a” • Two parts: condition, handling E.g. • Extensions: • 3a. Invalid identifier • 1. System signals error and reject entry • When possible write the condition as something that can be detected • 5a: System can not communication with external tax calculation system • 5a: External tax calculation system not working • If condition can arise within a range of steps • 3-6a: 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

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

25. 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?

26. Actors, Goal and Boundaries

27. Valid or Useful Use Cases • Which of these is a valid use case? • Negotiate a Supplier Contract • Handle Returns • LogIn • Move Piece on Game Board • All are valid, but at different level; better question is “what is a useful level to express use cases”

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

29. Applying Tests • Negotiate a Supplier Contract • Much broader and longer than an EBP • Handle returns • Ok with the boss. Seems like an EBP. Size is good • Log In • Not 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 function-level use cases representing subtasks or steps within a regular EBP-level use case.

30. Applying UML – Use Case Diagram

31. Diagram Notation

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

33. Uses Relationship

34. Extends Relationship

35. Extended Actor

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

38. Limitations of Use Cases

39. 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 • Access • Accessible over internet • Describe system as black box from user’s perspective

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