Use case descriptions chapter 4 facade iteration
1 / 16

- 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 '' - 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 l.jpg

Use Case DescriptionsChapter 4 – Facade Iteration

Initial Requirements

(Inception Phase)


First real cut at application requirements l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg

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

Packaging l.jpg

  • 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!!