A pretty good requirements analysis checklist

Recently I was asked for a high level requirements plan for a large IT conversion.  I googled around a little for something standard.  I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people.   I then rifled my files to find the example below.

This summary plan frames up interactions with business subject matter experts and their review of results.  The table lays out the steps, “granularity” (meaning how often each step is carried out), what comes out of each step, who does the work, and offers a few notes.

Before the table, here are two important definitions:

  • Sponsor: Very early on in your project you should identify the one person who you need to make happy in order to succeed.   The bigger the project, the higher up the sponsor.  Keep in touch to make sure they know what’s going on, keep them happy, and if something happens that will make them not happy don’t keep it secret.  Maintain a vibrant risk/issue process so that you can give them early warning of bad possibilities and they can help early.
  • Stakeholder: A stakeholder is anyone who will benefit from or be harmed by your project.  Requirements come from stakeholders.  Be sure to build support even with the latter group if at all possible, and at least make the adjustments that will keep them from working to prevent you from succeeding.

Careful, this is just an empty vessel.  Within this high level framework a team can apply whatever requirements techniques they want.  (In fact, I highly recommend structured analysis techniques like use cases or process models, but that’s for the requirements team and this framework is for the PM).  Of course a smaller effort suitable for agile techniques wouldn’t need something like this.  This is for big transitions like conversion to a new COTS package, for example, where it is easy to get lost in the detail.

Hopefully if you’re a PM on a big project you’ll find this framework as useful as I did.



Work Products

Responsible Group




Scope definition

Project manager

Defines context for requirements gathering by defining project objectives, constraints, stakeholders, and schedule



Interview checklist

Stakeholder overview

Requirements Standards

Requirements team

Project manager

Requirements team with PM


Interviewchecklist should include date range, meeting participants, meeting objectives in terms of expected objects specified


At least once per stakeholder group

Meeting notes

Risks / Issues / Actions

Draft Stakeholder Group requirements

Requirements team

Stakeholder group requirements are from the point of view of a single stakeholder group only

Stakeholder Validation

At least once per stakeholder group

Stakeholder feedback on / correctionsto the three items resulting from Interviews

Requirements team, stakeholder group


Either after all interviews or throughout the interview process

Project Requirements

Requirements team (with stakeholder groups)

Project Requirements result from analysis/refinement of requirements by resolution of inconsistencies, conflicts, and errors discovered in close review.This step should involve dialog with stakeholder groups.


PMO, Stakeholder Groups, Project Sponsor

Approved project requirements

Project management

 Here are some of the other references I found along the way, caveat emptor:

2 thoughts on “A pretty good requirements analysis checklist

  1. James Smith

    Hi, I am peter ross I own business in the USA. The blog you have posted was very informative keep posting stuff like this. I would like to read more from you.

Leave a Reply

Your email address will not be published. Required fields are marked *