1. 01.11.2015 Object Oriented Analysis & Design & UML (Unified Modeling Language) 1 Part II: Requirements The requirements workflow Use case modeling Advanced use case modeling

2. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 2 Requirements Workflow Most of the work is in Inception and Elaboration phases Discover and reach agreement on requirements: what you are going to build Express requirements in the language of the user Solve the conflicting requirements problem Build high-level specifications Prioritize the requirements

3. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 3 Iterations in SW Development

4. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 4 Requirements and UML Use Case is not the only set of requirements specifies Functional Requirements: “what the system will do” many non-functional requirements in a system (constraints on the system): Performance Reliability Maintainability Quality …

5. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 5 Workflow Model Contains – Workers (icons) and Tasks (cogs) Arrows indicate flow of work This is not “exact” it is merely a “normal” workflow We extend the UP workflow to include non-functional requirements also

6. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 6 Requirements Workflow

7. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 7 Extending Requirements Workflow

8. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 8 Importance of Requirements Discovering what the stakeholders want the system to do. Failure here will cause project failure Lack of user involvement is a major cause of project failure Requirement should drive the rest of system development

9. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 9 Requirements: The Crossroad Requirements study is the crossroad All other project practices are directed by the requirements

10. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 10 Defining Requirements Specification of “what” should be implemented not “how” Functional and Non-functional requirements Functional requirements: What behavior system should offer Non-functional requirements : A specific property of the system A constraint on the system It is easier to include some “how”, but it must be mostly “what” Produce SRS Document the System Requirements Specification

11. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 11 Well-formed Requirements UML does not have a specific tool Book suggests the format the shall do Separate Functional from non-functional requirements Functional what the system should do Non-functional constraints on the system

12. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 12 Requirement Types Functional Requirements A process the system has to perform Information the system must contain Nonfunctional Requirements Behavioral properties the system must have Operational Performance Security Cultural and political

13. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 13 Functional Requirements Functional Requirement DescriptionExamples

14. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 14 Nonfunctional Requirements Nonfunctional Requirement DescriptionExamples

15. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 15 ATM SW Requirements Functional requirements 1. The ATM system shall check the validity of the inserted ATM card 2. The ATM system shall validate the PIN number entered by the customer. 3. The ATM system shall dispense no more than $250 against any ATM card in 24-hour period. Non-functional requirements 1. The ATM system shall be written in C++. 2. The ATM system shall communicate with the bank using 256-bit encryption. 3. The ATM system shall validate and ATM card in three seconds or less. 4. The ATM system shall validate a PIN number in three seconds or less

16. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 16 Documenting Requirements

17. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 17 Use Case UC modeling is a form of Requirements Engineering Uses Actors Use Cases Relationships System Boundary Activities: Find the system boundary Find the actors Find the use cases Specify the use case Create scenarios

18. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 18 Use case modeling

19. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 19 System Boundary Separates the system from its environment Boundary is defined by who or what uses the system Represented by a box labeled with the system name Actors are outside Use Cases are inside

20. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 20 Actor The role some external entity adopts when interacting with the system Represents a role played by a user or another system Actor is a stereotype of class Use “stick person” to represent actors Actors are always external to the system System might maintain internal representation of the actors Example: Customer

21. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 21 Identifying Actors Who or what uses the system? What role do they play? Who installs the system? What starts and shuts down the system? Who maintains the system? What other system interact with ours? Who provides input? Things that happen at a given time can be an Actor To find actors ask: “Who or what uses or interacts with the system?”

22. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 22 Use Cases A specification of sequences or actions Happens by interacting with outside actors Something the actor wants the system to do Always started by an actor Always specified from the user point of view Naming: Verb with an object e.g. Place Order Representation: an Oval with name inside Place Order GetStatus OnOrder To find use cases ask: “How does each actor use the system?” and “What does the system do for each actor?”

23. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 23 Identifying Use Cases Iterative process Start with a name Ask questions What function will user want form the system? What triggers system behavior store/retrieve information Are actors notified by the system? What external events affect the system?

24. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 24 Example: Mail order system

25. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 25 Use Case Specification UML has no standard Template is normally used UC name Identifier Actors Preconditions/post-conditions Flow of events (steps in UC) the

26. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 26 Use case example Use case: ManageBasket ID: UC10 Actors: Customer Preconditions: 1. The shopping basket contents are visible. Flow of events: 1. The use case starts when the Customer selects an item from the basket. 2. If the Customer selects “delete item” 1. The system removes the item from the basket 3. If the Customer types a new quantity 1. The system updates the quantity on the item in the basket. Postconditions: 1. The basket contents have been updated.

27. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 27 Detail a use case

28. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 28 Branching etc.. Simple branching can be specified within a UC Complex ones may require a separate UC Use IF and indented (dot numbered) actions when necessary use alternative flows and post-conditions for each usecase

29. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 29

30. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 30 Repetition etc.. Use For statements Use dot-numbered indented set of statements n. For (iteration expression) n.1 Do something n.2 Do something else n.3 … n+1 Use While to represent repetition of a sequence of actions n. While (Boolean condition) n.1 Do something n.2 Do something else n.3 … n+1

31. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 31

32. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 32

33. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 33 Requirements Tracing Map (functional) requirements to Use Cases Requirements Traceability Matrix

34. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 34 Complex Use Cases UC should be simple If there are complex branching, iteration etc.: use Scenarios Scenario: One specific path through a UC Each Main Flow will be a scenario Scenarios do not branch Each possible branch is a potential Scenario Each UC has exactly one “primary scenario” (perfect world path) There are many secondary scenarios

35. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 35 Scenarios Primary Scenario Secondary Scenario How many Secondary scenarios? Pick the most important ones Group similar ones Use risk factor as a guidance

36. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 36

37. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 37

38. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 38 Actor Generalization Used to simplify diagrams Customer & SalesAgent Triggers the same use-cases Only difference is the CalculateCommission Too many crossed lines For the common behavior There should be another role: Purchaser The other roles are derived

39. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 39 Actor Generalization To express the common actor behavior Actors communicate with the same set of use cases Sometimes the parent actors are concrete But good style dictates actors to be abstract Substitutability principle: A descendant actor is replaced Anywhere the parent is expected Used to test the correctness Example: Replace Purchaser by Customer or SalesAgent

40. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 40 Use Case Generalization Used to represent one or more use cases are the special type of a more general case Use it only if the diagram is simplified! The child use case Automatically inherits all features from its parent The child use case may Inherit features from their parent use case Add new features Override (change) inherited some of the features

41. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 41 Restrictions to Override The child automatically inherits all features from its parent. But not every type of use case element may be overridden! Use case elementInheritAddOverride RelationshipYYN PreconditionYYY PostconditionYYY Step in main flowYYY Alternative flowYYY AttributeYYN OperationYYY

42. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 42 Use Case Generalization: Example The parent use case: FindProduct Two specializations FindBook FindCD

43. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 43 Conventions in Documentation Use normal text For inherited feature of parent With no change Use italic text For overridden feature of parent Use bold text to add features to the child

44. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 44 Parent Use Case Specification

45. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 45 Child Use Case Specifications

46. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 46 «include» Used to include the behavior of one use case called supplier into the flow of another one called client Is a little bit like a function call Prevents repeating the use cases The client use case executes until the point of inclusion Specify exact point of inclusion! then the execution passes to the supplier when the supplier finishes control returns to the client again

47. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 47 Example to «include»

48. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 48 Specification for «include»

49. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 49 «extend» Adds a new behavior to an existing use case at a predefined extension point Base: The use case that is extended Provides extension points used to add new behaviors Does not know anything about the extensions use case is complete without its extensions Extension: The use case that modifies the behavior of the base use case Can access and modifies all base attributes and operations Provides a set of extension segments to insert extension points are not numbered in specification «extend» provides a good way To deal with exceptional cases

50. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 50 Example to «extend»

51. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 51 Specification for «extend»

52. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 52 The Extension Use Case Generally are not complete Might have pre and post conditions Consists of one or more behavior fragments Known as insertion segments Rules: The «extend» relationship must specify the extension points in the base use-case The number of insertion points must Match the number of insertion segments Two extension use case might «extend» the same base use case, at the same extension point the order of execution is indeterminate

53. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 53 Extension use case example

54. 01.11.2015Object Oriented Analysis & Design & UML (Unified Modeling Language) 54 When to use advanced features? If they simplify the use case model The best use cases are the simple ones The model must be understandable by all stakeholders Actors and use cases are easily understood Actor generalization is more difficult to grasp Heavy use of «include» makes the complete picture harder to visualize «extend» is very hardly understood the meaning of «extend» is widely misunderstood

55. 01.11.2015 Object Oriented Analysis & Design & UML (Unified Modeling Language) 55 End of Chapter