5 minute read

Automate Requirements Gathering for Web Development Project Managers

Mar 14, 2019 / Project management

Last Updated: Sunday, May 19th, 2019

*Note: This is a working document, and will continue to be iterated upon to include more detail, features, and resources. Feel free to check back later!

Much of the internal work that a project manager is required to do when it comes to web development projects can be automated. Or, the very least, “template-ized”.

“Template-tizing” Requirements Gathering

With any web development project, the requirements gathering phase is the most crucial step of defining a project’s success. It is the job of the project manager to work with the client (product owner), the design team, the development team, and their own internal management to define the scope, budget, and timeline of a project.

Websites share characteristics. They share components, features, functionality, and attributes ranging from something as trivial as a website header, all the way down to legal accessibility considerations.

It is because of this resemblance that you can create a framework for which all requirement and specification documentation should be built by. A document that other project managers can download, duplicate, and populate content into. Sure, you may have to consider different “genres” of websites, you do not need to use a robust e-commerce requirements document template to build a simple lead generation WordPress site, but the document you do create will be naturally adaptable.

Structure of the Template

Section 1: Document Overview

State the purpose of the document. Clearly explain that this document is to be drafted, revised, finalized, and then signed off on by all stakeholders by the time the project moves into development (or in chunks of user stories if you are trying to follow more of an agile framework)

Section 2: Stakeholders

Define the major roles and responsibilities of each individual from both the web development agency and the client’s side, so that you know exactly who you should contact when third party blockers arise.

Stakeholder Identification

The “Responsibility” column should be as detailed as possible. The client needs to understand what being an executive sponsor for the project means. One role I’ve been adding to this table lately is Product Owner. I then write out the responsibilities of the product owner to include expectations of time dedicated to the project, project vision and business goal considerations, etc.

Section 3: Business Overview

Provide a little context around the business, the industry, and the project goals. Why is this company coming to you to build a new website? What do they expect the website to do for their business?

Section 4: Discovery

Include UML diagrams of the company’s current internal systems, including but not limited to ERP systems, marketing automation flows, external or third party API’s, creative and branding standards, and user details (who will be visiting or using the site, e.g., Guests, Registered Users, Admin Panel Employees, etc.)

Section 5: Business Requirements

Depending on the type of website, your internal development team, and the client’s experience with web development, there are many ways you can go about describing the business requirements of the new website.

For larger, complex e-commerce implementations working with a client experienced in web development and a team of developers who are comfortable working in a sprint based framework, I like to write user stories.

“As a B2C guest user, I should be able to compare products that are for sale on the website for attributes such as price, color, size, weight, and application.”

For more simple, marketing oriented static websites with clients who are not very experienced in building websites, I like to be more explicit in the business requirements. I like to describe how they will go into the admin panel to create a new blog post. I like to state how they will be able to edit the SEO metadata of that blog post. I leave the conversation less open-ended, and more yes/no oriented.

Section 6: Design Requirements

I recommend having finished the wireframes and high fidelity designs for the new website before tackling this section of the requirements document.

This is your chance to explain to the developers how the website should behave when the user interacts with the front end UI. What hover effects should the user see when they hover over main navigation links? What buttons should trigger popups, and what buttons should be links to other pages?

I usually take flat file PNG’s of the design source files, split them into blocks, and use a tool like Mac’s Preview to add bright pink numbered circles next to each component with any sort of dynamic functionality.

I’ll then take that annotated block, insert it as an image into this section of the requirements document, and then explain the functionality of each bright pink circle. For example:


Project managers are already as busy as can be, without even taking into account the amount of internal work that is needed of them. You may not be able to automate conversations with teams and meetings with clients, but if you can make your like a bit easier by creating your own framework for requirements gathering, you may find yourself with a little more time on your hands.

*Note: If this post gets enough traction, I’ll post a downloadable version of the template I created for Magento E-Commerce project requirements gathering. Use the “Tweet” button near the title of this post to Tweet me and let me know if you’d like to get a copy! I can email you one until I post a copy here.