Department or Program Name

[SYSTEM/APPLICATION NAME]
TEMPLATE Formal Requirements Review Resource Workbook

Template

Formal Requirements Review Resource Workbook

TABLE OF CONTENTS
Business Needs/Core Requirements Interview Record..............................................3 Supervisor........................................................................................................................3 Down line..........................................................................................................................3 Down line..........................................................................................................................3 Facilitated Team Deliverable Review Process.............................................................4 Requirements Review Sample Agenda ................................................................11 Business Requirements Review Checklist.................................................................12 Business Requirements Review Findings Summary................................................15

2009 Regents of the University of Minnesota. All rights reserved.

Page 2

Template

Formal Requirements Review Resource Workbook

Business Needs/Core Requirements Interview Record

The Interview Record is used to document the interviews that are done as part of gathering business requirements. Included here is a sample Interview Record that was used for the Enterprise GIS Project.

Business Needs/Core Requirements Interview Record Enterprise GIS Project

Date: Name: Location: Objective: Position:

Interviewer:

Introduction:
The University of Minnesota is preparing a business case and an eventual RFP for a University-wide GIS solution. GIS means many things to many people, ranging from AutoCAD to Space Management to GPS tracking. Our plan is to navigate through the process of identifying stakeholders, preparing a list of vendors available, generating a high-level set of business needs and functionality the organization would expect from a GIS system, and sending out a Request for Information. This will give us some better understanding as we then work with vendors to educate ourselves to the options of GIS while educating the vendors to our actual needs. You are being interviewed as a key stakeholder or subject matter expert in describing the Universitys GIS needs.

Pre-requisites:

None

Question Summary:
1. What does GIS mean to you? 2. Do you/your area currently use any form of GIS technology? 3. What are three things you think you could do to change how you do business given GIS technology in your area: a. Number 1 b. Number 2 c. Number 3 4. Do you know of any GIS technology used by your peers in other institutions or government agencies that is similar to what you could/would do? Do you consider this to be an advantage? 5. Are you or anyone in your area working with vendors to understand or deploy GIS technology? 6. Please identify additional business or technical subject matter experts that we should talk with: Name Business/Technical Role

Notes and Issues:

2009 Regents of the University of Minnesota. All rights reserved. Page 3

Template

Formal Requirements Review Resource Workbook

Enter notes and Issues

Facilitated Team Deliverable Review Process

This document describes the process to prepare for, conduct, and respond to issues identified during a formal team deliverable review process.

Roles
Note: One person can play multiple roles. Having multiple roles during the review process will depend on the size of the review:

Role
Project Manager (PM) Lead Author Moderator

Description
Person held accountable for ensuring project success, leading the project team to achieve its objectives, ensuring effective communications with management and other non-project organizations, and ensuring that project problems are identified and resolved in a timely manner. Person held accountable for deliverables in their discipline area and leading the team in that discipline to achieve the objectives. Person who wrote the deliverable and clarifies the issues brought up in the review. Person responsible for scheduling the meeting, ensuring that the attendees have the deliverable in a timely manner, ensuring the meeting stays on topic, on time and accomplishes the stated goal(s). Facilitator is a term often used interchangeably with Moderator. Person responsible for adequately reviewing the deliverable and documenting any issue. Designated person responsible for documenting discussion topics, decisions and action items.

Reviewer Scribe

Phases 1.0 Planning

Tasks
1. Determine appropriate type of review 2. Form review team and verify availability of each member 3. Set up the review meeting at least two weeks in advance 4. Prepare the deliverable 1. Prepare the review team for the review meeting 2. Identify special issues or goals that require additional attention 1. Evaluate the deliverable, noting all issues in the Review Findings Form, before the review meeting 2. Send the completed form to Author, Scribe, and Moderator 1. Lead the meeting, soliciting feedback and keeping on task 2. Document all issues, noting source, description and severity 3. Provide feedback on the deliverable by identifying issues Note: Solutions belong in the Rework phase 1. Assess the issues identified in the review meeting 2. Correct defects or log in defect tracking tool 3. Document the action taken for all issues 1. Confirm that all issues have been addressed

Owner
PM, Lead PM, Lead Moderator Author Moderator, Author Moderator Reviewer Reviewer Moderator Scribe Reviewer Moderator

2.0 Orientation 3.0 Preparation 4.0 Review

Meeting

5.0 Rework 6.0 Verify

Author Author Author PM, Lead

2009 Regents of the University of Minnesota. All rights reserved.

Page 4

Template

Formal Requirements Review Resource Workbook

Phases

Tasks
appropriately 2. Check the completed deliverable into the projects configuration management system

Owner
Author

Checklists, Templates and Links

Review Findings Summary Form Deliverables Review Checklist Review Meeting Summary

Goal
Optimize the effectiveness and quality of our reviews and reviewer feedback by ensuring the appropriate planning, preparation, and participation through a standard set of procedures and guidelines.

Deliverable Verification Process

As part of the SDLC, review processes for each SDLC Phase have been established. Formal team reviews will be required for Business Requirements, Technical Design, and Testing deliverables. Formal team reviews for other project deliverables, such as Business Case, Charter, and project close out are recommended. More information on the SDLC milestones, activities, and deliverables to be formally reviewed by project stakeholders and project teams can be found on the US PMO website. The information in this document is designed to take University Services project teams through effective formal team reviews of key project deliverables before those deliverables are passed to the next phase for execution.

1.0

Planning Phase 1.1 Objectives

1.2

Gather review package. Form review team. Determine dates for meetings.

Procedures
Project Manager and Lead determine the deliverable to be reviewed. Is this a large deliverable? Should it be broken down into manageable deliverables to be reviewed? Project Manager and Lead determine review method and project team members involved in the decision. Formal Inspection Peer Review Walkthrough Desk Check Project Manager and Lead determine Reviewers and Project Manager checks with Management to determine availability. Depending on the type of review that has been selected, a Review Team is made up of the following: o Author of the deliverable o Moderator o Scribe o Reviewers

2009 Regents of the University of Minnesota. All rights reserved.

Page 5

Template

Formal Requirements Review Resource Workbook

Knowledgeable peers with at least one person not working on the project Stakeholders of the deliverable One person new to the process and/or a person who lacks the knowledge of area the deliverable addresses Management, if applicable A representative of QA, if applicable Project Manager sets up work assignments for Review Team. Project Manager and Lead determine if an orientation meeting is needed. Author prepares deliverable to be reviewed. Author notifies Moderator that the deliverable is complete. Author provides Moderator with an estimate as to how long a Reviewer will take to adequately review the deliverable. Moderator ensures that Review Team is selected. Moderator schedules the review meeting. For maximum effectiveness and efficiency, the review meeting should be as short as possible. Moderator invites Review Team at minimum two weeks in advance. If an Email is used instead of an orientation meeting, Moderator ensures review package is complete to be emailed to Review Team at minimum five business days in advance and documents the areas that would be covered in the Orientation phase. Otherwise, Moderator schedules the orientation meeting at minimum five business days in advance. Moderator checks with Project Manager and Lead to reschedule the review based on who cannot attend. Project Manager and Lead take into consideration getting Reviewers feedback outside of the meeting if they cannot attend. Moderator reviews at a high-level the deliverable for completeness and readiness before providing it to Review Team. Ensures that the deliverable is of a reasonable size to be reviewed. Moderator reviews and enhances checklist(s) and form(s) if needed. Moderator compiles review packet. Deliverable Kickoff Sheet Checklist Copies or locations of upstream and/or reference materials

2.0

Orientation Phase 2.1 Objectives

Present the introduction or overview of project. Hand out the review material (or provide links to deliverable). Explain the review process and outline the goals of the review. Set the expectations for the review meeting. Communicate individual roles (e.g. Scribe, Reviewer). Discuss expected time involvement for preparation. Confirm review date with Review Team.

Note: The objectives can be met by either a meeting (recommended for large projects) or via Email.

2.2

Procedures

2009 Regents of the University of Minnesota. All rights reserved.

Page 6

Template

Formal Requirements Review Resource Workbook

Moderator hands out (or provides link to) review material, checklists, and review forms. Moderator notifies Review Team the task the time spent on the review should be put under. Author provides overview or demo, answers questions on project, and points out special items to pay attention to. Moderator explains review process and review meeting expectations. Remind Reviewers of general meeting guidelines. Point out key guidelines if necessary. Identify the major or minor issues on Review Findings Summary form. Identify severity of issue (major or minor) on Review Findings Summary form. Note that grammar and spelling issues should be on a separate review form or on the deliverable. This should not be brought up in the review meeting. If there is a show-stopper identified in the deliverable, inform Moderator immediately so a decision can be made to reschedule the review and revise the deliverable. The Review Preparation Form should be emailed to Scribe, Author, and Moderator at minimum one business day before the review meeting. Moderator identifies Scribe. Moderator sets preparation expectations, discusses expected time involvement, confirms review date and gets confirmation from Reviewers. Author does not change the deliverable once it has been given to Reviewers if the deliverable was sent as a link to the deliverable.

3.0

Preparation Phase 3.1 Objectives

Maximize use of time during the review meeting. Prioritize review findings. Concentrate on the major issues. Document all issues.

3.2

Procedures
Reviewer allocates adequate time to prepare for review. Reviewer reviews the deliverable and any associated preparation materials. Reviewer uses checklists as guidelines. Think beyond the checklists are there any other issues? Reviewer completes Review Preparation Form. Organizes issues by sections of the deliverable being reviewed. Prioritizes findings within sections: Major, Minor. Writes out a clear, brief description of each finding. Reviewer notes grammar issues separately from Review Findings Summary form, on a working copy of the deliverable or on a separate paper. Reviewer emails completed Review Preparation Form to Author, Scribe, and Moderator at minimum one business day before the review meeting. Reviewer is prepared to present issues in their order of importance from major to minor. Author, Scribe, and Moderator review the completed Review Preparation Forms from Reviewers.

3.3

What to Bring to the Review

2009 Regents of the University of Minnesota. All rights reserved.

Page 7

Template

Formal Requirements Review Resource Workbook

Deliverable being reviewed Completed Review Preparation Form Notes on grammar issues to be given to Author

4.0

Review Meeting Phase 4.1 Objectives

Provide opportunity for group synergy. Create shared knowledge of deliverable.

4.2

Identify major and minor issues in deliverable.

Author is available for clarification. Author needs to remember that only the deliverable is being reviewedavoid being defensive. Moderator arrives at meeting location early to prepare. Sets up equipment. Brings in additional chairs. Prepares dial-in attendees. Moderator introduces Review Team, if needed. Moderator briefly explains the purpose and importance of meeting. Moderator reviews key principles of meeting. Focus comments on the deliverable, not Author. Identify issues. Do not discuss solutions. Give list of grammar issues to Author. Do not discuss grammar issues during review. One person speaks at a time. Moderator identifies the option for discussion: Solicit feedback on issues, seeking confirmation/verification from the group. Do not discuss (or have a very brief discussion) whether issue is a defect. Moderator verifies Reviewers have the version of the deliverable that was handed out or sent out during Orientation Phase or whether the Author has made any significant changes that could affect the review if the deliverable was not given as a link. Moderator moves through the deliverable in sectionssummarize, do not read line by line. Scribe records all issues raised. Scribe records the following information for each issue. (Recommendation: Record so that everyone can see it.) Deliverable source Severity Description Who brought it up Scribe combines issues list and reviewer feedback and provides to Author. Reviewer provides constructive feedback (positive or negative) on deliverable. Reviewer critiques the deliverable, not Author. Reviewer identifies issues, not solutions.

Procedures

5.0

Rework Phase

2009 Regents of the University of Minnesota. All rights reserved.

Page 8

Template

Formal Requirements Review Resource Workbook

5.1

Objectives
Assess each issue. If it is a defect, remove it if necessary. If it is an issue, then resolve the issue.

5.2

Produce written summary of major issues.

Author corrects defects and typo found, resolves issues raised and modifies deliverable accordingly. Author marks issues list (provided in the Review Meeting phase) to indicate action taken. Author corrects any other project documents based on issues identified in the reviewed deliverable. Author records any uncorrected defects in the projects defect tracking system. When finished, Author documents issue resolution and reworked deliverable for verification.

Procedures

6.0

Verify Phase 6.1 Objectives

Assess the reworked deliverable. Pass or fail the deliverable.

6.2

Procedures

Author reports the number of major and minor issues/defects found and corrected and the actual rework effort to the Lead and/or Project Manager. Lead and/or Project Manager confirms that Author has addressed every item on the issues list. Lead and/or Project Manager determines whether Author made appropriate decisions as to which defects not to remove, which issues not to resolve, and which improvement suggestions not to implement. Lead and/or Project Manager examines the modified deliverable to determine whether the rework has been performed correctly. Lead and/or Project Manager reports any findings to Author, so rework can be declared complete, incorrect rework can be redone, or items that were not originally pursued can be addressed. Moderator performs sign-off. (If required, sign-off includes selected or all Reviewers.) Author checks the deliverable into the projects configuration management system.

6.3

Exit Criteria
All of Authors review objectives are satisfied. Issues raised during the review are tracked to closure. All major defects are corrected. Uncorrected defects are logged in the projects defect tracking system. The modified deliverable has been checked into the projects configuration management system. If changes were required in earlier project deliverables, those deliverables have been correctly modified, checked into the projects configuration management system and any necessary regression tests were passed.

Glossary
2009 Regents of the University of Minnesota. All rights reserved. Page 9

Template

Formal Requirements Review Resource Workbook

Major issue

Defects that would cause further errors in downstream deliverables making it harder to correct; would affect the results or behavior in an adverse way; affects large areas Defects that would not have impacts that are far reaching or broad; areas of functionality that can either be worked around or ignored; affects limited areas Defects that can be overlooked with no loss of functionality. Ex: grammar and spelling errors.

Minor issue

Grammar issue

2009 Regents of the University of Minnesota. All rights reserved.

Page 10

Template

Formal Requirements Review Resource Workbook

Requirements Review Sample Agenda [Project Name] Business Requirements Review Meeting
Meeting Purpose

Agenda
And Meeting Report

To review and acknowledge the features and functionality defined by business as required within the proposed solution. The requirements developed in the Analysis/Requirements phase provides developers with a detailed description of the business capability to be developed. It is according to the Business Requirements Document that the capability is designed, built, and tested. Requirements gathering and elicitation involves close collaboration between all known end users. This meeting is to review the final business requirements to ensure completeness and correctness in preparation for turning over for detailed technical design and development. Date: Time: Location:

Facilitator Meeting Details Attendees

= present, = planned absence, = not present, conference call; use bold for names of Decision Makers =

Advanced Reading Materials: Business Requirements Document Review Findings Summary

Meeting Topics Administration: Meeting Overview Introductions Review: Business Requirements Document Discuss and Approve: Agreement to continue with features and functionality described Next Steps: Transition to technical delivery team(s) for Detailed Technical Design Change management to address modifications, additions, and changes to the defined business requirements Business Requirements Document N/A Reference Led By Time 5 minutes

60 minutes

15 minutes

N/A

10 minutes

Open Forum Summarize and Close

N/A

2009 Regents of the University of Minnesota. All rights reserved.

Page 11

Template

Formal Requirements Review Resource Workbook

Business Requirements Review Checklist Business Requirements Review Checklist

Checklist Description: This checklist captures common elements that should be present in any business requirements definition document. It is presented during the Business Requirements Review process to stimulate thought, guide brainstorming, and to ensure the business-defined features and functionality being outlined contains all proper requirements considerations. To ensure that the system you are preparing to build fully addresses the necessary user and technical needs, features, and functionality, assess the requirements considerations that apply to your subject matter expertise and business needs. Project Name: Reviewer: Date: Project Manager:

Business Requirements Document Format

Is each requirement numbered or uniquely identifiable from other requirements (document uses numbered outline codes, etc.)? Is each requirement written in clear, concise, unambiguous language? Is something described as a standard without citing the specific source? Is any necessary information missing from a requirement? If so, is it identified as TBD and how it will be accounted for during design? Are there any of the following weasel words e.g. various, mostly, suitable, integrate, maybe, consistent, robust, modular, user-friendly, superb, good?? Are there different possible interpretations of the requirements? Are use cases or other process flow mapping used to increase readability? Are there screen prints to aid in defining the requirements? Are the terms that can have more than one meaning qualified so that the desired meaning is readily apparent? Are the performance criteria quantified such that they are testable? Is each requirement free from content and grammatical errors? Is the implementation priority of each requirement included? Are all requirements actually requirements, not design or implementation solutions? Are the requirements an adequate baseline for design?

Comments

Requirements Completeness
Have the following areas been addressed: Administrative Requirements Legal and Regulatory Requirements Information Security and Access Requirements Application and User Interface Requirements Data Requirements with Field Definitions Data Storage and Retention Requirements Error Management
2009 Regents of the University of Minnesota. All rights reserved.

Comments

Page 12

Template

Formal Requirements Review Resource Workbook

Quality Assurance Requirements Migration/Conversion Requirements Reporting and Management Information Requirements Business Continuity and Recover Requirements User Help and Application Documentation Requirements Client Acceptance Requirements

Requirements Content
Are performance objectives properly specified from the user's point of view (expected response time, processing time, data transfer, and system throughput, etc.)? Does the Business Requirements Document include all of the known customer or system needs? Are the requirements clearly stated as to what is needed at the requirements level rather than suggest how it might be implemented? Have reliability, serviceability, maintainability and performance objectives been identified? Is each requirement in scope for the project? Can all of the requirements be implemented within known constraints? Are al the external and internal interfaces properly identified and documented? Were appropriate steps taken to validate the requirements and operational concept? Are all inter-dependencies identified? Have algorithms intrinsic to the functional requirements been defined? Is the expected behavior documented for all anticipated error conditions? Are all time-critical functions identified, and timing criteria specified for them? Are the customer profiles and expected user groups clearly defined? Are all the tasks the user wants to perform specified? Does each task specify the data used in the task and data resulting from the task? Is the level of security specified? Is the reliability specified, including the consequences of software failure? Is vital information protected via error detection and recovery? Are acceptable tradeoffs between competing attributes specified, such as between robustness and correctness?

Comments

Requirements Quality
Are the requirements written in user language? Do the users think so? Do all requirements avoid any conflicts with other requirements? Are the requirements expressed independently of design specifications? Are all requirements specified at a consistent level of detail? Are the requirements clear enough to be turned over to an independent group for implementation and still be understood? Is each requirement relevant to the problem and its solution? Can each be traced to its origin in the problem environment?

Comments

2009 Regents of the University of Minnesota. All rights reserved.

Page 13

Template

Formal Requirements Review Resource Workbook

Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied? Are all requirements feasible to implement given the defined project timeframe, scope, structure and budget? Are probable changes to the requirements, including the likelihood of each change, specified?

2009 Regents of the University of Minnesota. All rights reserved.

Page 14

Template

Formal Requirements Review Resource Workbook

Business Requirements Review Findings Summary

Use this worksheet as a tool for reviewers to document any issues or questions they have on the Business Requirements Document. REVIEW FINDINGS for <deliverable name> Reviewed by: Review Date:

Item #

Source Deliverable Section

Issue Description

2009 Regents of the University of Minnesota. All rights reserved.

Page 15