160 likes | 450 Views
Use Case Descriptions Chapter 4 – Facade Iteration. Initial Requirements (Inception Phase). First Real Cut at Application Requirements. Façade Use Cases Amount to ‘placeholders’ for expanded use cases (to come).
E N D
Use Case DescriptionsChapter 4 – Facade Iteration Initial Requirements (Inception Phase) 17
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.
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
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
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
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
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).”
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)
Start of 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.
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….
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.
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.
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…
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…
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.
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!!