17 1 Use Case Descriptions Chapter 4 – Facade Iteration Requirements Inception Phase

172 Objectives of Façade Iteration Requirements One of the first iterations in the Requirements lifecycle Done during Inception; Façade  Major identification only… Façade iteration contains only the minimum information that is needed. Includes names, short description/purpose of interaction Sources – Users cannot tell whole story – but can tell a lot. Need all the sources you can get: users, project team, industry experts, IT management, user management, owners of the data, etc. All have different perspectives. You need these different perspectives. Need to know HOW the system will be used! SMEs on project? (knows application domain) Great inputs: Domain Model; Business Rules; Vision, …

173 Steps in Façade Iteration – Gathering Requirements Knowledge 1. Create the Problem Statement Becomes the mission statement for the team. This may have already been done in Business Modeling 2. Identify and Review Existing Documentation and Intellectual Capital – Knowledge… Familiarize yourself with the history of this effort... Tried before? Who introduced it? Who want it built? Who do not? Project visible to upper management? Who are the stakeholders? What are the features they desire… What was ruled out before? Packages ever considered? (COTS??) If so, which ones?

174 Steps in Façade Iteration 3. Get Executive Sponsor’s Unique View (Again, may have been done in Business Modeling…) Your success rides on getting exact definition of the problem from ‘his/her’ perspective. Make meeting face to face – not . What is the Problem being Solved? –Four or five sentences or paragraphs Why is a System Required? –If not developed, fallout? Market share? Why is a Computer System Required? –Can tasks be done manually? All requirements require solving by computer? Who will be affected by the System Implementation? How? Identify all groups. Who will be affected positively? Negatively?

175 Steps in Façade Iteration 4. Identify the Users, Customers, and Related Groups from which info can be obtained; Need their expectations and perceptions; their goals? Get an organization chart for the user group that includes management. If possible, talk with a sampling of the users. If possible, talk with ‘customers’, such as clerks, shoppers, and pharmacists

176 Steps in Façade Iteration 5. Interview all these Stakeholders Individual Interviews JRPS – concentrated requirements gathering sessions – normally result in a set of Filled use cases. (Joint Requirements Planning Session) Think of others? Questionnaires? Surveys, Interviews, Research… Quarterly Newsletters, Business Journals…Many different styles of each!

177 Steps in Façade Iteration 6. Find the Actors Ask the executive sponsor; ask each stakeholder Who/What is impacted by the development of this application? 7.  Create Façade Use Cases not too much detail (will hurt iterative nature…) Important to identify the use case (two/three sentences) Develop the System Context Use Case See next overhead…. Contains basic, essential, high-level interactions system must support.

178 System Use Case Diagram First Create an overall Use Case Diagram that contains all actors and Use Cases. (System Use Case) Then, create a use case diagram for each use case as you proceed to document each of these with a use case description (narrative) using the Façade format – for now.

179 System Use Case Description System Use Case – the big Cookie! cites overall functions of entire system. Like a mission statement for the application Can be enlightening to go through this Good way to confirm users’ overall expected functionality Accompanying Use Case diagram visualizes the system interactions and captures the scope. Always create an overview, all-encompassing System Use Case Diagram and System Use Case Description….

1710 Steps in Façade Iteration for each Use Case…Requisite Pro Using the Word template, create a Use Case Description for each use case in Requisite Pro. Link Use Case Description into Rose Again, see Kulak and Guiney for Use Case template

1711 Attributes in Façade Iteration Again, very general – identify the use case – give it a short name (verb, object); action words; Identify the Actor(s) that trigger the use case… Include a short description; These are essential. Should also try to include pre and post conditions, and more (see ahead…) THINK: Refer to the Business Rules or Vision or both…. Will note that some classes in the Domain Model will be cited in the general narrative….(This is good!!) Review these Business Rules…. Are we addressing them? Are these constraints factored into the Use Case Narrative? You may add more or refine some. Go back and iterate the Business Rules already created…

1712 Attributes in Façade Iteration Identify Key Risk items associated with this Use Case; Refer to Risk List entry from Use Case… Create a link for risks that surface as you proceed through discussions with users. Need to be able to reference Risks List to mitigate… Establish the Scope of the use case. What activities lie inside the boundaries of the use case? Sets up scope boundaries between you and users. Activities that lie outside the boundary of the system…..

1713 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… Use phraseology from Prototype and Domain Model in text. Interface items and domain entries will become objects ahead….

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

1715 Verb Filter and Noun Filter Use strong verbs (See table on p. 79) Use strong, concrete nouns. (See table 4.5 on p. 80) avoid weak nouns such as data, report, system, form, template, paper…

1716 Façade Filter Façade use cases represent the most important interactions between the actors and the system. Don’t worry about non-functional requirements at this time. 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, and key attributes…

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

1718 Packaging You need to build packages of Use Cases (do this in Rose) to group Use Cases of similar ‘value’ or ‘functionality’ 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!!