1. 171 Introduction to Use Cases Facade Use Cases Initial Requirements

2. 2 First Real Cut at Application Requirements Façade Use Cases Amount to ‘placeholders’ for expanded use cases (to come). Contain name and short description of the interaction; contains initiating actors. Verb…objects. Typically, we do NOT know all the details. Want to capture the ‘architecturally significant’ use cases… (What are these???) Trying to identify key functions / risks / interactions at a global level.

3. 3 Introduction: Façade Use Cases Ensure façade use cases are user-centric and NOT technology-centric. Why? What does this mean? Again, these are the WHATS that the users want! These are the ‘behaviors’ of the system. Express in terms the users understand! Involve various sources early and frequently Many different stakeholders with diverse ‘takes’ on the application…

4. 4 Use Case Index This is a Table of Contents for your Use Cases (that will be developed). Single Sheet; table in Word For each Use Case in the index (include a designator (like UC1, UC2, …), followed by the use case name, short description (two or three sentences), actors, level (façade, filled, focused) date last updated (for now). You may also write a ‘short user story’ describing the use case objectives. If so, this must be very short!! “Façade use cases show the basic, essential, high-level interactions that this application must support (Constantine 1999).”

5. Use Case Number Use Case NameDescriptionActorsLevelDate of Update 1Upload Document Customer will be able to upload documents for translation Customers, Database Focused11/13/2006 2Translate DocumentThe System verifies that payment has been received from the billing company and proceeds to translate the source document. The language consultant reads and corrects errors in the virtual document. Billing Company, Language Consultant, Database Focused11/13/2006 3Ship DocumentSystem administrator arranges for shipments to customers. Shipping company ships final product hard copies and reports the status of shipments to the system administrator. Customer, Shipping company, System Administrator Focused11/13/2006 4Maintain DatabaseAdministrator corrects errors and updates all system databases. System Administrator, Database Focused11/13/2006 5Update Profile The customer is able to change their personal information. Customer, Database Focused11/13/2006 6Change Order The customer is able to change their order attributes. Customer, DatabaseFocused11/13/2006 7Retrieve DocumentCustomer retrieves target documents.Customer, DatabaseFocused11/13/2006 8Print DocumentSystem directs customers to Printing company. Printing company provides printing options to customers and the information is directed back to the System Administrator. Customer, Printing company, System Administrator Focused11/13/2006

6. 6 Façade Use case: Attributes (Rows) Name of the use case – short name (verb, object); action words; Actor(s) that trigger the use case… Level (façade, filled, focused…These refer to levels of granularity. Short Description – two three sentences: at the most! (story?) Leave room for the Basic Course of Events…(happy path) Pre and Post conditions, and more (see ahead…) Trigger (what initiates the use case…. They just don’t ‘start’) Business Rules Link (Reference Business Rules in your Use Cases Risk priority (reference your Risk List preferable by number or identifier) Link to text on non-functionals (quality metrics; constraints) here, if desired Date / author(s) We will add attributes like Alternate Paths, Extensions…later)

7. 7 Use Case Number:03 Use Case Name:Edit Member Account Actor (s):Buyer, Seller Maturity:Focused (note: not façade; has basic course of events too) Summary:This use case is started by a Buyer or a Seller. It provides the capability for one of these actors to edit their member profile. Basic Course of Events:Actor Action 1. This use case is started when a Buyer or Seller elects to edit their member profile. Perform S1-Login 3. The Actor updates their member profile. 6. The Actor confirms that the information is correct. {Profile Change} 8. This use case concludes when the Actor receives visual confirmation of the update. System Response 2. The System displays the Actor’s member profile and prompts the Actor to update it. 4. The System validates the information entered by the Actor. {Validate Information} 5. The System prompts the Actor for confirmation. 7. The System updates the Actor’s member profile to the member repository and informs the Actor that the information was updated successfully.

8. 8 Alternate Paths:A1 Change Member Profile At {Profile Change} the Member indicates that he/she entered incorrect information. The System immediately returns to the step 2. Exception Paths:E1 Handle Invalid Information At {Validate Information} if any fields are entered incorrectly. The System indicates the fields that were entered incorrectly and prompts the Buyer or Seller to make the necessary corrections. The flow of events is resumed at Basic Flow Step 2. Extension Points:{Change Profile }, {Validate Information} Triggers:The Buyer or Seller would like to edit their member profile. Assumptions:The Buyer or Seller is aware of the steps required to edit their member profile. Preconditions:The System is functioning properly. Actor already has a Profile stored in the Profile Database??? Post Conditions:The member profile was successfully updated to the member repository. Actor sent email to confirm changes. Reference - Business Rules:See Business Rules section: 2.3.1 and 2.3.5. Reference - Risks:See Risks List sections: 2.1 and 2.4. Author (s):Team3 Date:11-04-04 Continuing….

9. 9 Think About Non-Functional Requirements (Quality Constraints) You have seen ‘lists’ of non-functional requirements. Be aware of a number of examples of non-functional requirements that may be addressed in your application. Availability, compatibility, data integrity, extensibility, interoperability, maintainability, performance, portability, reliability, robustness, scalability, security, usability / achievability Know these! (be able to identify them…) Document these per use case Non-functional requirements normally not tied to specific use cases; normally threaded through a number of use cases. Capture in a Table These normally are found within a Supplementary Specifications Document…

10. 10 Verbiage in Use Case Use Verb-object phrases (stated before…) Sell Houses, Enroll in Course; Maintain Book… Should not be instances of classes Should not be tied to an organization structure, paper forms or computer implementation Refer to Prototype to see actions an actor expects to undertake…(ahead) Use phraseology from Prototype and Domain Model in text. Interface items and domain entries will become objects ahead…. Nice technique: Bold items or Italicize items in Use Case Specifications for which there is a glossary entry or a business entity in the Domain Model Have links for key words or entities to domain model / glossary.

11. 11 Candidate Use Case List Ensure each Use Case is ‘in scope.’ Actors must reflect the roles that people play – not the actual names of people. Note: Use Cases will often have multiple actors. Again: (repeating…) Actor must provide or receive a value from the system Do not tie your actors to your organization chart.

12. 12 User Interface Prototype Use storyboarding to elicit major, high-level end- user requirements. Document the interactions as seen in the storyboards as high level text to identify the Façade Use Cases. The details of the interactions (and likely more detailed user interface prototypes) will be used to capture the interactions use cases with more granularity. More on prototyping in the next series of slides.

13. 13 Verb Filter and Noun Filter Use strong verbs (‘generate’ ‘calculate’ ‘compute’ ) Use strong, concrete nouns. Avoid weak nouns such as data, report, system, form, template, paper…

14. 14 Façade Filter Façade use cases represent the most important interactions between the actors and the system. Don’t worry too much about non-functional requirements at this time. Will address more later. Façade use cases should be relatively abstract – so that they will cover a number of actual proposed interactions (scenarios). No implementation details! Façade use cases contain NO basic course of events….Only trying to identify significant Use Cases – for their functionality, their actors, pre and post conditions, triggers, and key attributes…

15. 15 Reviews Peer Reviews: Review the use cases carefully. Have a ‘SME’ available for business domain questions. Have reviews often and informally User Reviews: User review of your Façade use cases is critical. Every hour you spend in review could save many hours of work later!!! I RECOMMEND THAT TEAMS REVIEW EACH OTHER’S USE CASES!! Use Cases capture functional requirements… Sometimes called Requirements Analysis…I like to keep ‘Requirements’ and ‘Analysis’ somewhat separate.

16. 16 Packaging You need to build packages of Use Cases group Use Cases of similar ‘value’ or ‘functionality’

17. 17 Use Case Diagrams… (a graphical model) Withdraw MoneyTransfer Money Simply actors and use cases Can, of course, be much more detailed. Often the relationships are ‘tagged.’

18. 18 Extending the UML with Stereotyping  Know we have ‘Change’ in everything.  But very few graphics in UML.  Need to communicate special cases: –special classes –special kinds of use cases… –Extend UML for new ‘types’ –New types of model elements? –We often need customization of models for some projects.  Extend UML? No! Ability to stereotype is built in.

19. 19 Extending the UML with Stereotyping  Enter: Stereotyping. –Allow us to ‘refine’ / ‘reclassify’ ‘re-specify’ all model elements into a more specialized form rather than create additional symbols! –We might specify a Use Case as a > or class name with the stereotype: > or > etc. –Indicate that the symbol is still a Use Case – but a ‘special one’ perhaps in a ‘special context.’  Most common UML stereotyped element is the class.  Stereotyping makes these different model elements!!! –(Incidentally, additional icons can be added, if wanted…)

20. 20 Examples Choices (attributes) (methods) Authenticate User Withdraw Money A ‘special’ kind of class with special behaviors – a boundary class. A ‘special’ kind of Association – indicates a use case that supports a more fundamental use case – one that is more significant.

21. 21 Stereotypes in Modeling: Built-ins and User-Defined  Stereotypes can be used to ‘increase relevance’ of model elements, such as use cases in requirements gathering. –(Much controversy on ‘extend use cases’ and ‘include use cases’ Much more later: stereotypes: > and >  Use Cases are quite commonly stereotyped –A use case ‘may’ be specified in a separate document addressing all stereotypes –“Stereotyped element” implies that there are ‘special’ criteria. –e.g. A use case that is “mission critical” => must be processed within five seconds.  Classes may also very often stereotyped: –,, (as found in Analysis Modeling) A boundary class is a special kind of class that interacts directly with an actor…  Any UML modeling element may be stereotyped….

22. 22 Use Case Template (Be aware there are many many formats. Format is not critical. Content is.) One of many different kind of formats… Will discuss others in next lecture.

23. 23 Use Cases  Use Cases – a great tool that helps us to express interactions between system (application) and actors.  We can see the behaviors of the system.  We can see the scenarios (instantiation of a use case w/data)  Meaningful to customer who is concerned with the ‘whats’ of the system to see how system and actor interact with each other.  Successful development of Use Cases requires an understanding of the goals of each of the use cases, which, in turn, is developed from identified, required functionality – namely Features.

24. 24 Goals: Use Cases capture ‘Whats’  “ Context-free” use (that is, no design constraints)  Excellent for requirements gathering / modeling; analyzing and capturing desired user interactions  Numbers of Use Cases? –70-80 for very large system? –Medium sized – 20 to 50; –Small systems – fewer. Often 6 to 8 may be sufficient.  Smaller number forces abstraction. Desirable.  There is no ‘one size / number’ fits all. But there are guidelines in their development! (Coming)

25. 25 Goals of Use Cases  Interactions must present a value to actor. –actor may be an accounting system; general ledger system; person; customer; a relay; or thermostat… person, device, external system/database/file. Actors are external to the system.  Use Cases are black box representations –Do not show implementation-specific language –Do not want to imply how use case will be realized. –Do not include language such as: people, interface widgets (buttons, menus…), IFTHENELSE statements, pseudo-code, more… –Are written in language of the application domain. –Are ‘abstractions’ of detailed interactions. –  Capture stories addressing functional requirements…