TEMPLATE Requirements Review Workbook

8/4/2019 TEMPLATE Requirements Review Workbook

1/15

Department or Program Name

[SYSTEM/APPLICATION NAME]

TEMPLATE

FormalRequirements

ReviewResource


2/15

Resource

Template Formal Requirements Review Resource Workbook

TABLEOF 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


3/15


Business Needs/Core Requirements Interview Record

The Interview Record is used to document the interviews that are done as part of gathering businessrequirements. 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: Position:

Name:Location:Objective:

Interviewer:

Introduction:

The University of Minnesota is preparing a business case and an eventual RFP for a University-wide GISsolution. GIS means many things to many people, ranging from AutoCAD to Space Management to GPStracking. Our plan is to navigate through the process of identifying stakeholders, preparing a list ofvendors available, generating a high-level set of business needs and functionality the organization wouldexpect from a GIS system, and sending out a Request for Information. This will give us some betterunderstanding 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 expertin describing the Universitys GIS needs.

Pre-requisites:

N


4/15


Enter notes and Issues

Facilitated Team Deliverable Review Process

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

Roles

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

Role DescriptionProject Manager(PM)

Person held accountable for ensuring project success, leading the project team to achieveits objectives, ensuring effective communications with management and other non-projectorganizations, and ensuring that project problems are identified and resolved in a timelymanner.

Lead Person held accountable for deliverables in their discipline area and leading the team in

that discipline to achieve the objectives.Author Person who wrote the deliverable and clarifies the issues brought up in the review.Moderator 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 andaccomplishes the stated goal(s). Facilitator is a term often used interchangeably withModerator.

Reviewer Person responsible for adequately reviewing the deliverable and documenting any issue.Scribe Designated person responsible for documenting discussion topics, decisions and action

items.

Phases Tasks Owner 1.0 Planning 1. Determine appropriate type of review

2. Form review team and verify availability of eachb

PM, LeadPM, LeadM d t


5/15


Phases Tasks Owner appropriately

2. Check the completed deliverable into the projectsconfiguration management system

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 appropriateplanning, 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 teamreviews will be required for Business Requirements, Technical Design, and Testing deliverables. Formalteam 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 formallyreviewed 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 effectiveformal team reviews of key project deliverables before those deliverables are passed to the next phasefor execution.

1.0 Planning Phase

1.1 Objectives

Gather review package. Form review team.


6/15


Knowledgeable peers with at least one person notworking 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 Managersets up work assignments for Review Team.

Project Managerand Lead determine if an orientation meeting is needed.

Authorprepares deliverable to be reviewed.

Authornotifies Moderator that the deliverable is complete.

Authorprovides Moderator with an estimate as to how long a Reviewer will taketo adequately review the deliverable. Moderatorensures that Review Team is selected.

Moderatorschedules the review meeting. For maximum effectiveness and efficiency, the review meeting should be

as short as possible.

Moderatorinvites Review Team at minimum two weeks in advance.

If an Email is used instead of an orientation meeting, Moderatorensures reviewpackage is complete to be emailed to Review Team at minimum five businessdays in advance and documents the areas that would be covered in theOrientation phase. Otherwise, Moderatorschedules the orientation meeting atminimum five business days in advance.

Moderatorchecks with Project Manager and Lead to reschedule the reviewbased on who cannot attend. Project Managerand Lead take intoconsideration getting Reviewers feedback outside of the meeting if they cannotattend.

Moderatorreviews at a high-level the deliverable for completeness andreadiness before providing it to Review Team.

Ensures that the deliverable is of a reasonable size to be reviewed.

Moderatorreviews and enhances checklist(s) and form(s) if needed. Moderatorcompiles review packet.

Deliverable Kickoff Sheet


7/15


Moderatorhands out (or provides link to) review material, checklists, and reviewforms.

Moderatornotifies Review Team the task the time spent on the review shouldbe put under.

Authorprovides overview or demo, answers questions on project, and points outspecial items to pay attention to.

Moderatorexplains 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 reviewmeeting.

If there is a show-stopper identified in the deliverable, inform Moderatorimmediately so a decision can be made to reschedule the review andrevise the deliverable.

The Review Preparation Form should be emailed to Scribe, Author, andModeratorat minimum one business day before the review meeting.

Moderatoridentifies Scribe.

Moderatorsets preparation expectations, discusses expected time involvement,confirms review date and gets confirmation from Reviewers.

Authordoes not change the deliverable once it has been given to Reviewers ifthe 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.


8/15


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.

Identify major and minor issues in deliverable.

4.2 Procedures

Authoris available for clarification.

Authorneeds to remember that only the deliverable is being reviewedavoidbeing defensive.

Moderatorarrives at meeting location early to prepare. Sets up equipment. Brings in additional chairs. Prepares dial-in attendees.

Moderatorintroduces Review Team, if needed. Moderatorbriefly explains the purpose and importance of meeting.

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

Moderatoridentifies the option for discussion:

Solicit feedback on issues, seeking confirmation/verification from thegroup.

Do not discuss (or have a very brief discussion) whether issue is adefect.

M d t ifi R i h th i f th d li bl th t


9/15


5.1 Objectives

Assess each issue. If it is a defect, remove it if necessary.

If it is an issue, then resolve the issue.

Produce written summary of major issues.

5.2 Procedures

Author corrects defects and typo found, resolves issues raised and modifiesdeliverable accordingly. Author marks issues list (provided in the ReviewMeeting phase) to indicate action taken.

Author corrects any other project documents based on issues identified in thereviewed deliverable.

Author records any uncorrected defects in the projects defect tracking system. When finished, Author documents issue resolution and reworked deliverable for

verification.

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 andcorrected and the actual rework effort to the Lead and/or Project Manager.

Lead and/or Project Manager confirms that Author has addressed every item onthe issues list. Lead and/or Project Manager determines whether Author made

appropriate decisions as to which defects not to remove, which issues not toresolve, and which improvement suggestions not to implement.

Lead and/or Project Manager examines the modified deliverable to determinewhether the rework has been performed correctly. Lead and/or Project Managerreports any findings to Author so rework can be declared complete incorrect


10/15


Major issue Defects that would cause further errors in downstream deliverablesmaking it harder to correct; would affect the results or behavior in an

adverse way; affects large areas

Minor issue 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

Grammar issue Defects that can be overlooked with no loss of functionality. Ex:grammar and spelling errors.


11/15


Requirements Review Sample Agenda

AgendaAnd Meeting Report

Meeting Purpose To review and acknowledge the features and functionality defined by business as required withinthe 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 tothe 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 correctnessin preparation for turning over for detailed technical design and development.

Facilitator

Meeting Details Date:Time:Location:

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 Reference Led By Time

Administration: Meeting Overview Introductions

5 minutes

Review: Business Requirements Document

Business RequirementsDocument

60 minutes

Discuss and Approve: N/A 15 minutes

[Project Name]Business Requirements Review Meeting


12/15


Business Requirements Review Checklist

Business Requirements Review Checklist

Checklist Description: This checklist captures common elements that should be present in any businessrequirements definition document. It is presented during the Business Requirements Review process tostimulate thought, guide brainstorming, and to ensure the business-defined features and functionality beingoutlined contains all proper requirements considerations. To ensure that the system you are preparing to buildfully 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: Date:

Reviewer: Project Manager:

Business Requirements Document Format Comments

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 identifiedas 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 thedesired meaning is readily apparent?

Are the performance criteria quantified such that they are testable?


13/15


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 Comments

Are performance objectives properly specified from the user's point of view(expected response time, processing time, data transfer, and systemthroughput, etc.)?Does the Business Requirements Document include all of the known customeror system needs?Are the requirements clearly stated as to what is needed at the requirementslevel rather than suggest how it might be implemented?Have reliability, serviceability, maintainability and performance objectives beenidentified?

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 operationalconcept?

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?


14/15


Is each requirement testable? Will it be possible for independent testing todetermine 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 eachchange, specified?


15/15


Business Requirements Review Findings SummaryUse this worksheet as a tool for reviewers to document any issues or questions they have on the Business Requirements Document.

REVIEW FINDINGS

for

Reviewed by:Review Date:

Item #Source Deliverable

Section Issue Description

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

Documents

TEMPLATE Requirements Review Workbook