use case descriptions chapter 4 facade iteration
Skip this Video
Download Presentation
Use Case Descriptions Chapter 4 – Facade Iteration

Loading in 2 Seconds...

play fullscreen
1 / 16

use case descriptions chapter 4 facade iteration - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'use case descriptions chapter 4 facade iteration' - Anita

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
use case descriptions chapter 4 facade iteration

Use Case DescriptionsChapter 4 – Facade Iteration

Initial Requirements

(Inception Phase)


first real cut at application requirements
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
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
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
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
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
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
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
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
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
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
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
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 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…
  • 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!!!
    • Use Cases capture functional requirements…
    • Sometimes called Requirements Analysis…I like to keep ‘Requirements’ and ‘Analysis’ somewhat separate.
  • 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!!