1 / 15

Use Case Descriptions Chapter 4 – Facade Iteration

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

erasmus
Download Presentation

Use Case Descriptions Chapter 4 – Facade Iteration

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Use Case DescriptionsChapter 4 – Facade Iteration Initial Requirements (Inception Phase) 17

  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. Introduction: 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! These are the ‘behaviors’ of the system. • Express in terms the users understand! • Involve various sources early and frequently • Many different stakeholders with diverse ‘takes’ on the application…

  4. Use Case Index • 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). • You may also write a ‘short user story’ describing the use case objectives. If so, this must be very short!! • Book states (p. 73), “Façade use cases show the basic, essential, high-level interactions that this application must support (Constantine 1999).”

  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…These refer to levels of granularity. • Short Description – two three sentences: at the most! (story?) • Leave room for the Basic Course of Events…(happy path) • 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 (quality metrics; constraints) here, if desired • Date / author(s) • We will add attributes like Alternate Paths, Extensions…later)

  6. Continuing….

  7. Think About Non-Functional Requirements (Quality Constraints) • 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-functional requirements normally not tied to specific use cases; normally threaded through a number of use cases. • Capture in a Table • These normally are found within a Supplementary Specifications Document…

  8. 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 computerimplementation • 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…. • Nice technique: Bold items or Italicize items in Use Case Specifications for which there is a glossary entry or a business entity in the Domain Model • Have links for key words or entities to domain model / glossary.

  9. 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…) • Actor must provide or receive a value from the system • Do not tie your actors to your organizationchart.

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

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

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

  13. 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 functionalrequirements… • Sometimes called Requirements Analysis…I like to keep ‘Requirements’ and ‘Analysis’ somewhat separate.

  14. Packaging • You need to build packages of Use Cases group Use Cases of similar ‘value’ or ‘functionality’

More Related