18 years of proven training for business systems analysts in requirements and testing
IIBA Endorsed Education Provider

Roles

 

The execution of an Application Project can involve a number of different actors, each with a specific role and set of responsibilities. The following table defines all the different roles and responsibilities that can be found on an Application Development Project. These roles always exist although the size and characteristics of the project may cause the same person to carry out more than one role.

 

Add and remove roles as appropriate.  Make sure the responsibilities of each role are clearly understood.  It is as important to list client responsibilities to ensure client resources have the appropriate authority.

Role

Responsibilities

Roles

 

 

 

  Project Manager

Produce Project Definition Document.

Manage project schedule.

Manage project budget.

Manage change, issues risk and status.

  Technical Manager

Schedule and manage day-to-day development activities.

Resolve technical issues.

  Test/QA Manager

Define system test plan & test cases.

Execute system test plan.

Schedule testing resources.

Ensure application adheres to standards.

  Business Analyst

Analyze and document client requirements.

  Developer

Produce Prototype (optional).

Produce Design Document.

Code the application.

Unit test code.

Fix bugs in a timely manner.

  Tester

Test the application to ensure it complies with the Requirements & Design Documents.

 

 

<Client> Roles

 

  Sponsor/Champion

Sign-off on major deliverables and budget.

Participate in phase-end reviews.

Assign client resources to the project.

Eliminate roadblocks and motivate staff.

  Client Project Manager

Primary point of contact for Hallmark.

Sign-off on major deliverables.

Approve change requests & change budget.

Participate in phase-end reviews.

Coordinate client meetings, participation in workshops, training and status meetings.

  Other Client Representatives

Participate in analysis & design workshops.

Ensure the requirements specification meets the needs of the organization.

Participate in User Acceptance Testing.

 

 

TBD Roles

 

  Rollout manager

Plan and manage installation activities.

Plan/coordinate conversion activities.

  Support manager

Provide ongoing product support.

  Training manager

Develop training plan (with client lead).

Develop training material.

Train employees on the system.

  Documentation manager

Develop user documentation & help.

The purpose of an iterative development approach is to separate a development project into logical and manageable units for incremental delivery.  The completion of each iteration adds to the knowledge about the system being developed and reduces the risk when progressing to the next iteration.  It also provides a repeatable method for business system development.  It provides business user sign off and approval before continuing to commit resources to the project.

 

Reusability is also described throughout the system development process.  Reusing previously developed parts in a product is a significant way of decreasing the product’s life cycle cost.  Reuse in software engineering means deliverables that can be reused later.  This includes all the information and knowledge that has been developed, such as; system architectures, development methods, program code and completed algorithms.

Requirements Gathering & Writing Class

The Requirements Gathering and Writing class focuses on how to gather and write the different levels of requirements.  After attending Pierson’s training, customers have achieved a 30 – 40% time and cost saving in the requirements phase.  The class teaches how to implement UML and use case best practices for requirements gathering and writing for enhancements and new software development projects.  The workshop is one third lecture and two thirds hands on exercises for writing project scope definitions, business requirements and functional specifications requirements.

 

The seminar focus is on:

 

·         Understanding the different levels of requirements

 

·         The requirements management process

 

·         Characteristics and guidelines for writing effective requirements and use cases

 

·         Communication techniques for gathering requirements

 

·         Writing skills and instructions for writing successful scoping, requirements documents and detailed requirements

 

·         Practical exercises in scoping, business objectives, functional requirements, non-functional requirements, use cases and screen and reporting specifications

 

·         Writing and critiquing use cases and requirements using guidelines and checklists



Schedule

Date: June 2 – 4, 2010
Time: 1:00 pm to 5:00 pm EST
Duration: 3 half day sessions
Cost: $750.00
PDUs: 12
CDU’s towards CBAP recertification: 12

Register

Contact us to Register for the Requirements Gathering & Writing Virtual Class

Cost: $750.00

·         Live Instructor-Led Interactive sessions (4 hours per day over a 3 day period)

·         Training material presented via the web and live interactive instruction by phone or the web

·         Interactive exercises both in groups and individually

·         All participants receive printable .pdfs of materials

·         PDUs, CDUs and Certificates of successful completion are provided

Questions? Call or Email at 203- 322-1606 jmatthews@piersonrequirementsgroup.com

Click here to view the agenda

 

Instructor: Joy Matthews, Pierson Requirements Group, Inc.

Joy is the co-founder of Pierson Requirements Group which specializes in business systems requirements analysis and design best practices. Joy provides corporate training and consulting services to companies around the world and has assisted to implement requirements management best practices at hundreds of organizations in requirements gathering, requirements and system design methodologies.  Joy has over 20 years experience in Applications Development, Business Analysis, Requirements Management and Software Testing.

Use Case Template

Use Case #

#1

Author:

Author’s name

Iteration:

Filled (outlining the high level business requirements and identifying the alternate and exception scenarios)

Finished- completed in the Functional Specification to identify the detailed system requirements for the use case and how the  user interaction with the system should work

Name:

Use case name Verb noun

Category:

Category name – optional; use this field only if you’ve divided your use cases into functional groups (or categories).

Actor(s):

 End users performing this activity and/or systems that interface with this activity.

Description:

This use case describes…provide a brief summary of the use case.

Pre-Conditions

List any pre-conditions here in a bullet list.  What are the state of things prior to executing this use case?  What conditions must be true before this use case begins?  A pre-condition is a constraint that must be true before this use case can operate.  Often, other use cases are stated as pre-conditions.

E.g. database initialized, record already found, security established

Assumptions

Items that are outside the control of development (including the out of scope) AND must be in place before the use case can run.

Business Trigger

What is the business event that causes this use case to occur?

Flow of Events (Basic Path)

Step

Action 

This is the primary flow.  Supply the detailed flow descriptions here in a numbered style text.  You should have 3 -9 steps.  Document how the use case starts and ends.  Indicate what the customer wants the system to do.  Use the active voice.  The actor and the system perform the actions.  Use present tense.  Name the actor based upon the role that the actor represents in the problem domain.  The flow should contain the step #, Actor Action, System Action, Screen (if available) and Event.  The events are documented to better understand the major functions/processes the Actors are performing on the system. This information will later be used to create the event list template.

1

The use case begins when…

2

 

3

 

4

The use case ends when…

Post Conditions

List any post conditions here in a bullet list.  What are the state of things after you execute this use case?  What is the next step?  Indicate the successful post-conditions and the failed post-conditions.  E.g. Client added to the database, Resource ‘X’ assigned to project ‘Y’.

Alternate Scenarios

Step

Branching Action

1

Alternate flows are generally considered to be choices that are intentionally made by an actor.  Each alternate flow is labeled with an identifier in the form  A#1.  Each alternative flow is also named with a one-sentence description.  Each alternative flow has a set of steps numbered in sequential order.  It then statements are alternate scenarios.

Note:  the step number here refers to step in the basic path where the alternate scenario branches off of the basic path.

2

 

3

 

Exception

Scenarios

Exception flows are generally considered to be choices that are not intentionally made by the actor and normally result from significant error conditions.  What are the what ifs?  The errors that can happen.  Each exceptional flow is labeled with an identifier in the form E#1.  Each exceptional flow is also named with a one-sentence description.

Business Rules Validated

List any business rules associated with this use case, e.g. guests cannot order a quantity greater than 3 of any one item; to calculate tax in the state of Massachusetts, multiply the total by .05.

Special Requirements

In many situations you will uncover requirements that do not fall within the scope of the use case description, list those here, e.g. volumes, usability issues, time constraints, security issues.

Issues

List any questions and issues to be addressed by the end of the discovery stage.

Design Comments

This section is optional.  State any design comments and/or suggestions and clearly identify them as either comments/suggestions or as customer-stated, design constraints.  This can include suggestions or constraints on the GUI as well as other parts of the system.  These will be used as considerations by the design team when designing the classes that will implement the use case.  Also can use this section to document system rules.

 

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…


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