Use Case Template

Types of Questions:

Questions to open communication and creativity…

•          What do you think about…?

•          What options do you see…?

•          What are the pros/cons…?

•          How does the rest of the group feel?

Discovery questions -

•          What are your goals in developing this system/enhancement?

•          What critical problems, issues, or opportunities initiated this project?

•          What is the most important business goal of the system/enhancement?

Confirmation questions -

•          How will you recognize success?

•          Are we in agreement with how I’ve described this?

Evaluation questions -

•          Will the system/enhancement make the customer or you be more efficient? How?

•          What will the new system/enhancement accomplish that is not currently accomplished manually or with other systems?

•          Will the system/enhancement change the way you are doing things now? QA

Put yourself in the customers’ place:

Imagine yourself learning the user’s job

•          What tasks would you need to perform?

•          What questions would you have?

•          Who all performs this task?

Questions could begin with:

•          What else could…….

•          What happens when….

•          Would you ever need to…..

•          Does anyone ever…..

Try to bring out the user’s assumptions

•          What features or characteristics is the user expecting to be included without  having said so?

Walk through the processes that users follow to make decisions when performing tasks to extract the underlying logic.

•          Use Flowcharts, Activity Diagrams, Process Mapping

•          Decision Trees

•          Mind Mapping

10 Key Principles, and how Agile Development fundamentally differs from a more traditional Waterfall approach to software development, are as follows:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: Estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat…

Business Requirements Training	Dates
Developing Requirements & Selecting Software Packages (COTS) (Virtual 1)	March 2 - 3, 2010
The training provides a toolkit for the project team for how to develop requirements and select the best software solution (COTS).
Gathering & Writing Effective Business Requirements (Virtual 2)	March 4 - 5, 2010
How to gather, analyze and write effective project scope, functional and non-functional requirements documents using UML and Use Cases.
QA Testing Training
User Acceptance Testing (Virtual 3)	March 9 - 11 & July 13 - 15, 2010
The focus is on training the product owners and business users how to be an effective tester. The class provides a toolkit of techniques for conducting acceptance testing and handling defects.
Testing for Quality Assurance (Virtual 4)	June 1 - 4, 2010
Testing tool kit for the entire QA Testing Department.
Agile Training
Agile Requirements Gathering & Iteration Planning (Virtual 5)	April 14 - 16, 2010
The focus is to teach the project team the skill set they need to collaborate for Agile projects. The workshop provides training in collaboration techniques needed for gathering requirements, developing release/iteration plans and defining the iteration detailed requirements for Agile Projects.
Agile Modeling Techniques for Collaborative Solutions (Virtual 6)	May 5 - 7, 2010
The focus of the training is on the agile modeling techniques and developing skills needed by the entire agile project team to conduct successful collaborative projects.
UML & Business Modeling Training
Learning Use Cases and UML Techniques (Virtual 7)	April 13 - 14, 2010
How to create and interpret Use Cases and UML models and how the artifacts fit into the project life cycle for project initiation, business process definition and design
Conceptual & Logical Data Modeling Skills (Virtual	March 2 - 3, 2010
Focuses on the concepts of conceptual and logical data modeling and various effective techniques used to gather the necessary information needed to create the data model.
Business Process Management (BPM) Facilitation (Virtual 9)	July 15 - 16, 2010
Provides facilitation skills and techniques needed to conduct effective BPM workshops and business meetings. A real life company project is utilized to demonstrate how to facilitate the BPM process analysis and design stages.
Project Management Training
Project Planning & Estimating (Virtual 10)	June 8 - 10, 2010
Offers training in the facilitation and collaboration techniques and procedures that a Business Analyst and Project Manager would use to effectively plan and estimate a project.

--

Define the components of the Introduction

1. Participant Introductions
2. Administrative items and ground rule (get consensus of rules)
3. Present the agenda and process steps
4. Present the workshop purpose and deliverables
5. Ice breaker/group activity

 Identify the Agenda Activities

1. Tasks, scripts, questions needed to facilitate the step and identify the type of group interaction.  An agenda activity should feed to the next step on the agenda.  An agenda activity should consist of:

·         Steps/tasks and focus questions

·         Inputs for the activity

·         Techniques used

·         Deliverables wanted from the activity 

What are the step inputs?  Identify the templates, seed material and draft models being used for the step.

Closure

1. Review the issue list- assign dates and people to follow-up
2. Recap and Next steps- Ask the PM to review what’s next and thank everyone
3. Workshop Evaluation- use a written evaluation form or do a process check (pluses and deltas of the session)

 Sample Session Agenda:

PROJECT PLANNING WORKSHOP

·        INTRODUCTION

·        DESCRIBE THE CURRENT ENVIRONMENT

·        DEFINE BUSINESS OPPORTUNITIES

·        DEFINE THE OBJECTIVES

·        DEFINE REQUIREMENTS

·        DESCRIBE THE CONSTRAINTS

·        PRIORITIZE THE REQUIREMENTS

·        NEXT STEP AND RECAP

Detailed Use Case

Quality Assurance Checklist

Use Case Name:                    Verb/noun 

Use Case Number:                Follow current standards? (i.e. references to related systems) 

Iteration:                                Is iteration level noted? 

Description:                            Does the description:

1.      Begin with “the purpose of this use case is…”

2.      Clearly state the value provided to the actor

3.      Clearly state the purpose/goal of the use case                                 

Generic Scenario:                  The generic course of events should:                 

1.      Clearly state how the use case starts and ends (i.e. this use case starts when and ends when)

2.      Be written in the appropriate perspective (system perspective)

3.      Have a minimum of 3 steps identified

4.      Be consistent with description and within the scope of the description

5.      Use the active voice to describe the end user or system interface performing the steps

6.      Document the system solution, using ping pong, to identify the system interface responses clearly

7.      Identify links to other use cases, by underlining the use case name and reference the use case number

8.      Not document GUI but instead attach a prototype or an activity diagram

9.      Have no more than 9 or so steps

10.  Provide a step by step flow of events from the actor’s perspective.

Actors:                                    Are the correct actors identified?

1.      Are the users and/or systems that communicate with the solution identified?

2.      Are the actors a person or system other than the support system under development?

3.      Are the actors identified only involved in this use case? 

Alternate Scenario:                Are the alternate paths identified correctly?

1.      Is the path intentional by the actor and within the actor’s control?

2.      Does the title of the alternate describe the alternate path and tell why it is an alternate.

3.      Is the alternate using the appropriate numbering scheme and is referenced in the basic course of events section? (A1)

4.      Does the alternate successfully complete the use case?

Exceptions:                             Are the system exceptions identified?

1.      Do the exceptions result in a different outcome of the use case?

2.      Is the exception unintentional, an anticipated failure that needs a recovery plan?

3.      Is the exception using the appropriate numbering scheme (E1) and is referenced in the basic course of events section?

Trigger:                                 

1.      Is the event that causes the use case to occur present?

2.      Is the active voice used?

3.      Is the trigger a business event, not a system event? 

Assumptions:

1.      Is the item outside the control of development (including the out of scope) AND must be in place before the use case can run? 

Preconditions:                       

1.      Ensure the precondition is not the first step of the basic course of events.

2.      Is the item inside the control of development and in place prior to the execution of the use case?   

Post conditions:

1.      Ensure post condition is not the last step of the basic course of events.

2.      Does the post condition declare the state after the use case execution?  

Related Business Rules:

1.      Are the business rules specific to this use case?

2.      Is it a business related rule rather than a system rule?

3.      Should be written as a declarative statement

Issues:                                               

Should be NONE

§         Determine High-Level Functions

     1.    Are we just changing the front-end of the system or rewriting (re-architecting) the whole   system?

     2.    What will this system do that the current system already does?

     3.    What will this system do that you are doing manually now?

     4.    What will this system do that is entirely new?

     5.    Does the current system do things that this system will not do?

     6.    What is the functional scope of this system?   (list high-level functions)

     7.    How do these functions interact with each other?

     8.    What is the level of complexity?

     9.    Are there other systems/projects this system will interface with?

    10.   Will the converted system access legacy files, databases, dual databases, or new files and databases?

    11.   What is the functional core of the system?

    12.   What are your priorities?

§         Determine Development, Deployment, Usage Constraints

    1.    What is the timeframe for conversion?

    2.    Are there time constraints in converting the system?  What are they?

    3.    Are there time constraints in deploying the system?  What are they?

    4.    Are there any dependencies on other systems in completing the system?  Please specify.

    5.    Are there budget constraints in converting this system?  How much?

    6.    Are there resource constraints in converting the system (do we have the in-house expertise we           need)?

    7.    Do we have management and user commitment and buy-in?

8.        Are there technical constraints to converting this system? What are they?

9.        Is there remote processing?  Are there scheduler constraints to consider (CA7 and/or CA7 Agent)?

§         System Research

    1.    Who are the most important players in terms of - Knowledge  - Politics?

    2.    Is there any existing system documentation?  If so, where?

    3.    Who else should we talk to?

§         Assumptions/Inclusions

    1.    List assumptions

§         Issues

1.        List open issues, responsible parties, resolution date

§         Exclusions

    1.    List exclusions

Determine Business Objectives:

    1.    Why do you want to redo the system?

    2.    How will the new version of the system help you?

    3.    What are your objectives in having this system?

    4.    Who are the key stakeholders and users? Do their goals differ? If so, how?

    5.    How does the system map to business goals?

    6.    What is the most important business goal of the system?

    7.    Will the system change the way you are doing things now?

    8.    Will the system help you be more efficient?   How?

    9.    What are the system deliverables? 

   10.   What will the converted system accomplish that the current system cannot    accomplish?

   11.   Will the output of the converted system be the same or different than the      current system?

   12.   Will the new system have additional functionality?    What?

   13.   Will the new system have better performance?    To what extent?

   14.   Will the new system help you be more efficient?    To what extent?

   15.   Will the screens look different?  How?

   16.   What is most important (rank in order of importance): 

                  Application is easier to use

                  Application has nicer front-end

                  Application has additional functionality (list)

                  Application is more efficient

                  Application is redesigned to better reflect the business

Determine Future Needs

   1.    What business requirements will this system address?

2.        Is the data and/or functionality shared by other (many) business areas?  If so, which?

3.        If the reports were dynamic, what would they do differently?

4.        How much historical information is required?

Determine Current Problems

   1.    What are the current problems with your system today?

   2.    Do you have to do things manually that you would like to automate?

   3.    Do you have performance problems that need to change?

   4.    Do you have functional limitations that you’d like to change?

5.        What is the risk of not converting the system?

6.        Which reports do you currently use?  What data on the report is important?  How do you use the information?

7.        Are there specific bottlenecks to getting at information?

8.        How do you analyze the information you currently receive?  What type of data is used?  How do you currently get the data?  How often do you get new data?

9.        What type of ad hoc analysis do you typically perform?  Who requests ad hoc information?  What do you do with the information?

Determine System Users

   1.    Who will be using the system?

   2.    What are the titles and roles of the people who will use the system?

3.        What are their levels of expertise?

Determine Criteria for Success

    1.    What do we need to accomplish to make this project successful?

    2.    What do we need to change to make this project successful?

    3.    What buy-in do we need?

    4.    Are we lacking any critical elements such as budget, resource allocation, or    support?

    5.    What are the training considerations for developers and users?

System Research

    1.    Who are the most important players in terms of - Knowledge  - Politics?

    2.    Is there any existing system documentation?  If so, where?

    3.    Who else should we talk to?

Assumptions and Issues

    1.    List assumptions

    2.    List open issues, responsible parties, resolution date

Information from this questionnaire should be used to develop the detailed business requirements in the Project Requirements document.  Ask these questions for each high- level business process to identify the detailed business processes, associated functionality, functional and reporting deliverables.

§         Determine High-Level Functions

    1.    What will the process do that you are doing manually now?

    2.    If using purchased packages, what do they do?

    3.    What will this process/function do that is entirely new?

    4.    Are there related processes/functions within the scope of this process?    (list these)

    5.    How do these processes/functions interact with each other?

    6.    What is the level of complexity of each process/function?

    7.    Are there other systems/projects that must interface?  (What are they?)

    8.    What is the functional core of this process?

    9.    What are the priorities for this process?

Determine Development, Deployment, Usage Constraints

    1.    Are there time constraints in developing the process/function?  What are they?

    2.    Are there time constraints in deploying the process/function?  What are they?

    3.    Are there any dependencies on other systems in completing the system?   Please specify.

    4.    Are there budget constraints in developing this process/function?   How much?

    5.    Are there resource constraints in developing the process/function? (in-house expertise available)?

    6.    Do we have management and user commitment and buy-in?

7.        Are there technical constraints to developing this process/function? What are they?

8.        Is there remote processing?  Are there scheduler constraints to consider (CA7 and/or CA7 Agent)?

§         System Research

    1.    Who are the most important players in terms of:

                - Knowledge

                - Politics

    2.    Is there any existing system documentation?  If so, where?

    3.    Who else should we talk to?

§         Assumptions

    1.    List assumptions

§         Issues/Risks

1.        List open issues, responsible parties, resolution date

Inclusions -   List inclusions

§         Exclusions - List exclusions