Capturing the Requirements

1. Capturing the Requirements

2. Contents • [1 step] system analyst performs the Find ActorandUse Case activity • prepare first version of a use-case model • feature list and domain or business model • [2 step] architect(s) will identify the architecturally significant use cases • provide input to the prioritization of use cases to be developed in the current iteration • [3 step] use-case specifiers describe all use cases that are prioritized • [4 step] User-interface designers suggest suitable user interfaces for each actor based on the use cases • this can be done in parallel with 3 step • [5 step] system analyst restructures use-case model

3. Structure the Use-Case Model Find Actors and Use Cases Prototype User-Interface Prioritize Use Cases Detail a Use Case User-Interface Designer Use-Case Specifier System Analyst Architect Workflow

4. Find Actors and Use Cases • Identifying actors and use cases is the most crucial activity for getting the requirements right • system analyst’s responsibility • system analyst requires input from a team, customer, user, and other analysis • Starting point of this activity may be various • business model, domain model, brief vision statement, detailed requirements specification …. • This activity consist of four steps : result is use-case model • finding the actors • finding the use cases • briefly describing each use case • describing the use-case model as a whole • These steps can be performed concurrently

5. Find Actors and Use Cases • Input • Business Model(or Domain Model) • Supplementary requirements • Feature list • Output • Use-case model(outlined) • Glossary

6. Find Actors and Use Cases : Finding Actors • This task depends on the starting point • with business model : straightforward • one actor for each worker in the business • one actor for each business actor • with/without domain model : together with the customer • identifies the users and tries to organize them into categories that represent actors • Two criteria for eliciting candidate actors • it should be possible to identify at least one user who can enact the candidate actor • there should be a minimum of overlap between the roles that instances of different actors play in relation to the system

7. Find Actors and Use Cases : Finding Actors • Input • Business Model(or Domain Model) • Supplementary requirements • Feature list • Output • new version of use-case model with an updated set of actors with brief description

8. Find Actors and Use Cases : Finding Actors • ATM operator • regularly checks its operational states • regularly refills cashes and receipt papers • He is the authorized person for turning on,off and maintaining ATMs • Customers

9. Find Actors and Use Cases : Finding Use Cases • If starting point is a business model, a use case is suggested for every role of each worker • who participates in a business use-case realization • who will use the information system • Otherwise, system analyst identifies the use cases through workshop with the customers and users • System analyst goes through the actors, and suggests candidates for use cases for each actor • actor will typically need use case to support its work • We try to create use cases that are easy to modify, review, test, and manage as a unit

10. Find Actors and Use Cases : Finding Use Cases • Input • Business Model(or Domain Model) • Supplementary requirements • Feature list • Output • more structured use case

11. Find Actors and Use Cases : Finding Use Cases • Tips ! • Take out commonalties among use-cases • <use> relationship

12. Find Actors and Use Cases : Finding Use Cases • More structured use-case model(Fig. 2)

13. Find Actors and Use Cases : Finding Use Cases • Tips ! • to improve • modularity, extensibility, understandability, flexibility, reusability • thus, define a new “coordinating use case”

14. Find Actors and Use Cases : Finding Use Cases • More structured use-case model(Fig. 3)

15. Find Actors and Use Cases : Finding Use Cases • Tips ! • when a sub-behavior of use case is significant , extract it using <extend> relation(reusability) • to improve transparency to actors, by hiding conditional execution of some use cases

16. Find Actors and Use Cases : Finding Use Cases • More structured use-case model(Fig. 4)

17. Find Actors and Use Cases : Finding Use Cases • Fig. 4-1

18. Find Actors and Use Cases : Finding Use Cases • Fig. 4-2

19. Find Actors and Use Cases : Finding Use Cases • H.A. #4. Draw “more structured” use-case model for the actor ATM operator

20. Find Actors and Use Cases : Briefly Describing Each Use Case • Describing with a few sentences that summarize the actions • later, a step-by-step description of what the system needs to do when interacting with its actors

21. Find Actors and Use Cases : Briefly Describing Each Use Case • Input • Business Model(or Domain Model) • Supplementary requirements • Feature list • Output • more structured, well-described use case

22. Find Actors and Use Cases : Briefly Describing Each Use Case • ATM operator security check • Access ATM’s internal console(operator access only). • Gets ATM operator’s ID & password. • Prints ATM operator’s private GUI. • ATM Turn on(by ATM operator) • use ATM operator security check • Select Turn on menu. • ATM Turn Off(by ATM operator) • use ATM operator security check. • Select Turn off menu. • ATM Refill Cash(by ATM operator) • use ATM operator security check. • Select Refill Cash menu. • Refill Cash.

23. Find Actors and Use Cases : Briefly Describing Each Use Case • ATM Refill Receipt • use ATM operator security check • Select Refill Cash menu. • Refill receipt. • ATM Emergency Repair • use ATM operator security check • Select repair menu. • Take appropriate actions for the emergency status.

24. Finding Actors and Use Cases : Describing the Use-Case Model as a Whole • It it not enough to describe and understand each use case in isolation • we also need to see the whole picture • need to explain how the use cases and actors are related to each other • There’s no strict rule for composing a whole picture ! • To ensure consistency between several use cases, it is practical to develop a glossary of terms • these terms may be derived from classes in a domain/business model • Use-case model need not to be flat model • can be organized by use-case package

25. Finding Actors and Use Cases : Describing the Use-Case Model as a Whole • Input • Business Model(or Domain Model) • Supplementary requirements • Feature list • Output • consistent use-case model set • survey description of the use-case model : tagged value

26. Finding Actors and Use Cases : Describing the Use-Case Model as a Whole • Tips ! • To make model consistent, take out commonalties between “Security check for customer” and “Security check for operator”, use <extends> relation • Fig. 5

27. Finding Actors and Use Cases : Describing the Use-Case Model as a Whole • Survey description • Customers use “ATM Transaction” to process “deposit”, “withdraw”, “transfer”, “query”. • “ATM Transaction” uses “Receipt management” & “Customer security check”. • “ATM Transaction” extends to “Updates & manages ATM transactions” so that it provides updates & management functionality to the customers. • ATM operator operates “Turn On”, “Turn Off”, “Refill Cash”, “Refill Receipt”, “Emergency Repair”. • “Turn On”, “Turn Off”, “Refill Cash”, “Refill Receipt”, “Emergency Repair” uses “ATM operator security check”. • “Customer security check” & “ATM operator security check” extends “security check”.

28. Prioritize Use Cases • 2nd Step in overall workflow, done by architects • Purpose of this activity is • to provide input to the prioritization of use cases to determine which of them need to be developed in early iterations • which can be developed in later iterations • Results are captured in an architectural view of the use-case model • this view is used as an input when planning what to be developed within an iteration

29. Prioritize Use Cases • Input • Use-case model[outlined] • Supplementary requirements • Glossary • Output • Architecture description[view of the use-case model]

30. Prioritize Use Cases • Fig. 6

31. Detail a Use Case • 3rd Step in overall workflow • Purpose of detailing use case is to describe its flow of events in detail • including how the use case starts, ends, and interacts with actors • With the use-case model and the associated use-case diagrams as starting point, • the individual use-case speicifiers can now describe each use case in detail, step-by-step

32. Detail a Use Case • Input • Use-case model[outlined] • Supplementary requirements • Glossary • Output • Use case[detailed]

33. Detail a Use Case : Structuring Use Case Description • Goal is to make a description precise but easy to read • Use case defines state transition diagrams • state that use-case instances enter and possible transitions between those states • state transition is a sequence of actions triggered by an event • We must describe possible state transition simply and precisely • proven technique is to choose one complete basic path • basic path should be normal, that is, users perceive it as the the one most commonly andit yields the most obvious value to the actor • Use cases need to be understood by developers, customers and users • should always be described using plain English

34. Detail a Use Case : Structuring Use Case Description • Input • Business Model(or Domain Model) • Supplementary requirements • Feature list • Output • well structured use case, with enough information

35. Detail a Use Case : Structuring Use Case Description • Flow of Events : ATM Transaction • Basic path • Precondition : TRUE • 1. Use “security check” • 2. ATM prints GUI. • 3. Customer selects transaction type. • 4. Process selected transaction. • Use “withdrawal” or “transfer”, etc. • 5. Ask customer for the next transaction. • 6. If customer selects “Yes”, go back to #2 . • 6’.If customer selects “No”, finishes transaction. • 7. Use “receipt management” • Postcondition : “account balance is changed correctly.”

36. Detail a Use Case : Structuring Use Case Description • Flow of Events : Security Check • Basic path • Precondition : “card is a valid card.” • 1. Customer inserts a card. • 2. Customer enters a valid password. • 3. ATM authorizes access. • Postcondition : “customers get authorization” • Alternative path • Precondition : “card is a valid card.” • 1. Customer inserts a card. • 2. Customer enters a invalid password. • 3. ATM doesn’t authorize access. • Postcondition : “customers fail to get authorization.”

37. Detail a Use Case : Structuring Use Case Description • Flow of Events : Withdrawal • Basic path • Precondition : “customers get authorization.” • 1. Customer enters valid amount of money(within the balance limit). • 2. ATM changes account balance. • 3. ATM pays cash. • Postcondition : “account balance is changed correctly.” • Alternative path • Precondition : “customers get authorization.” • 1. Customer enters invalid amount of money(over the balance limit). • 2. ATM reports invalid amount. • Postcondition : “account balance is not changed”

38. Detail a Use Case : Structuring Use Case Description • Flow of Events : Transfer • Basic path • Precondition : “customers get authorization.” • 1. Customer enters account info to transfer money. • 2. Customer enters valid amount of money(within the balance limit). • 3. ATM requests the account & amount authorization for the money transfer. • 4. Customer authorizes transaction. • 5. ATM process money transfer transaction & updates account balance. • Postcondition : “account balance is changed correctly.” • Alternative path • Precondition : “customers get authorization.” • 1. Customer enters account info to transfer money. • 2. Customer enters valid amount of money(within the balance limit). • 3. ATM requests the account & amount authorization for the money transfer. • 4. Customer doesn’t authorize transaction. • Postcondition : “account balance is not changed.”

39. Detail a Use Case : Structuring Use Case Description • H.A. #5. Describe Flow of Events for “ Deposit” and “Balance Check”

40. Prototype User Interface • 4th Step in overall workflow • Purpose of this activity is to build a prototype of user interface • up to now, use-case diagrams, survey description, detailed use-case description have been made • Using user interfaces, let the user perform the use cases effectively • logical user-interface design(what the actors need from U.I) • physical user-interface design(how U.I deliver this needs) • End result is a set of user-interface sketches and user-interface prototypes that specify the look-and-feel

41. Prototype User Interface • Input • Use-case model • Supplementary requirements • Use case[described] • Glossary • Output • Use-interface prototype

42. Prototype User Interface : Logical User-Interface Design • When actors interact with the system, they will use and manipulate user-interface elements(attributes of use case) • user-interface designer identifies and specifies these elements for one actor at a time by going through all use cases • single element may participate in many use cases • Questions should be answered by each actor • which elements are needed to enable the use cases ? • how should they be related to each other ? • how will they be used in the different use cases ? • what should they look like ? • how should they be manipulated ?

43. Prototype User Interface : Logical User-Interface Design • Input • Use-case model • Supplementary requirements • Use case[described] • Glossary • Output • logical elements in use-interface

44. Prototype User Interface : Logical User-Interface Design • Logical UI elements • cash card slot • receipts dispenser • receipts • key(number) pad for customer’s input • screen • account information, transaction information • cash dispenser • ATM operator console • power button

45. Prototype User Interface : Logical User-Interface Design • Fig. 10

46. Prototype User Interface : Physical User-Interface Design • Sketching additional elements needed to combine various elements into complete user interfaces • using containers(folders), windows, tools and controls • these can be prepared after(concurrently) with the sticky-notes • These prototypes can be built with a rapid prototyping tool • Reviewers should verify each user interface • allows the actor to navigate properly • provides a consistent look and feel and works consistently(tab ordering, accelerator keys..) • complies with relevant standards such as colors, button size and placement of toolbars

47. Prototype User Interface : Physical User-Interface Design • Input • Use-case model • Supplementary requirements • Use case[described] • Glossary • Output • physical sketches of user-interface

48. Prototype User Interface : Physical User-Interface Design • Physical sketches for ATM • Fig. 11

49. Structure the Use-Case Model • 5th Step in overall workflow • Use-case model is structured to • extract general and shared use-case description of functionality • extract additional or optional use-case description of functionality • Purpose is to make use cases more easier to understand and work with • Activities in this steps are • identifying shared descriptions of functionality • identifying additional and optional descriptions of functionality • identifying other relationships between use cases

50. Structure the Use-Case Model • Input • Use-case model[outlined] • Supplementary requirements • Use case[described] • Glossary • Output • Use-case model[structured]