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

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. Typically, we do NOT know all the details. Trying to identify key functions / risks / interactions at a global level.

3 Revisiting the Various Users (Stakeholders) Inputs / buy-ins absolutely essential! No one source has all views. Some know domain too well Some are new NEED a SME – on your team or readily available Differentiate between what is said and what is meant! Remember: many, diverse sources of inputs; some more valuable than others; each have their own biases. Ensure façade use cases are user-centric and NOT technology- centric. Why? What does this mean? Involve various sources early and frequently

4 Steps Prior to Actually Creating the Façade Iteration (1 of 2) Note: most of these activities (not all) we have accomplished via our Business Modeling exercises. Create the problem statement (We included this in our Vision Document) Learn what you can about the existing business models, domain models and unique viewpoints. Identify the stakeholders and determine actors (not necessarily the same…) Interview / question, … learn all you can from them. Identify ‘contacts.’ Develop a Use Case Index (survey) – a list of Façade Use Cases Note: this is for the Application to be developed. Should be a subset or derived from your Business Use Case Model

5 Steps Prior to Actually Creating the Façade Iteration (2 of 2) Start tracking (keep track of) non-functional requirements as they are made known. Start business rules (have this – will need iterations) Start the risk analysis list (have this – will need iterations ) Develop Statement of Work (discussed in previous lecture) Statement of Work identifies what will be accomplished by whom, etc. Also establishes boundaries (scope) of application that all agree to. Start developing the Façade Use Case entries (template contents) – to be discussed Begin the user interface prototyping (storyboarding) – to be discussed further

6 Steps in Façade Iteration for each Use Case…Requisite Pro Using the Word template, create a Use Case Description for each use case using Requisite Pro. (Optional for Senior Project Students) Link Use Case Description into Rose Again, see Kulak and Guiney for Use Case template

7 Use Case Survey (Index) Entries This is like a table of contents for your Use Cases that will be developed. Single Sheet. For each Use Case in the index (develop a Table using Word) include a ‘number’ (like 1…), 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).”

8 Attributes (rows) in Façade Iteration 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. Leave room for the Basic Course of Events… Pre and Post conditions, and more (see ahead…) Trigger Business Rules Link (Reference Business Rules in your Use Cases (consider format on pg. 82 or other format) Risk priority (reference your Risk List preferable by number or identifier) Link to text on non-functionals here, if desired Date / author(s) We will add attributes like Alternate Paths, Extensions…later)

9 Start of Non-Functional Requirements Note the significant list of non-functional requirements on pp 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.

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

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

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

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

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). Certainly no implementation details. Façade use cases contain NO basic course of events….Only trying to identify Use Cases – for their functionality, their actors, pre and post conditions, triggers, and key attributes…

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 Packaging You need to build packages of Use Cases (do this in Rose) to group Use Cases of similar ‘value’ or ‘functionality’ Incorporate within the Use Case View (more later) Will be quite significant later for creating static and dynamic diagrams; apportioning the workload, creating the architecture, and much MUCH more. Name your packages. These are essential components of your architecture!!