1. 171 Use Case Descriptions Chapter 4 – Facade Iteration Initial Requirements (Inception Phase)

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 Intro: 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! 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 Survey (Index) Entries This is a Table of Contents for your Use Cases (that will be developed). Single Sheet; table in Word As you discover a Use Case, index it. 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). Book states (p. 73), “Façade use cases show the basic, essential, high-level interactions that this application must support (Constantine 1999).”

5. 5 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…) Short Description – two three sentences: at the most! Leave room for the Basic Course of Events…(happy path) Pre and Post conditions, and more (see ahead…) Trigger Business Rules Link (List some Business Rules.) Risk priority (Cite Risks from Domain Analysis) Link to text on non-functionals here, if desired Date / author(s) We will add attributes like Alternate Paths, Extensions…later)

6. 6 Use Case Number:03 Use Case Name:Edit Member Account Actor (s):Buyer, Seller Maturity:Focused 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.

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

8. 8 Think About Non-Functional Requirements Note the significant list of non-functional requirements on pp. 76-77. 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, as shown on page 4.1. Non-functionals normally not tied to specific use cases; normally threaded through a number of use cases. In RUP: Analysis Mechanisms… Capture in a Table Go into Supplementary Specifications Document…

9. 9 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 or Domain Analysis 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 in Use Case Specifications for which there is a glossary entry or a business entity in the Domain Model

10. 10 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…) Use Cases must provide or receive a value from the system Do not tie your actors to your organization chart.

11. 11 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 for focused and filled use cases later. More on prototyping in the next series of slides.

12. 12 Verb Filter and Noun Filter Use strong verbs (See table in textbook) Use strong, concrete nouns. (See table) Avoid weak nouns such as data, report, system, form, template, paper…

13. 13 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). Certainly 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…

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

15. 15 Homework #6 – Deliverable 3 You are to develop a use case index and a set of façade level use cases. Your use cases will be presented in class. After acceptance, they are to be incorporated into RTC. Due date: TBD.