Developing product requirements: Tools and agile process


Typical approaches to defining product requirements vary based on organizational experience and expertise maturity. In smaller organizations, the approach can be as simple as a list of desired features that a product manager submits to designers to detail. In larger organizations, an executive may initiate a high-level charter to a program management office (PMO), who would then assign business analysts to hold a series of meetings to identify high-level requirements from sponsoring stakeholders as part of a project initiation process. However, more often than not this leads to missed key functionality and variable delivery acceptance quality.

This paper outlines product development tools and an adaptable process in an agile sprint framework—tailored for easier use with non-technical stakeholders, with internal business partners, with external end-users; and customers—all with voice of the customer (VoC) research validation. Using context diagrams, user stories, use cases, process flows, and prototypes to capture, develop, and prioritize product requirements, this process will help define meaningful project scope, specify delivery acceptance criteria, and better communicate intended functionality and benefits to others.


Various studies have shown that around 60% of product and project errors originate with the requirements definition and analysis activities. Incomplete and poor quality requirements slow the product design and development project phases by causing initiation and planning rework and by increasing time needed to define and clarify the objectives and requirements. They also result in increased production costs due to downstream change requests required to fix execution errors and omissions. The challenge then is how to determine that the right requirements have been specified, that an adequate listing of requirements have been defined to begin work, and that those requirements are effectively documented to minimize misinterpretation.

The tools and process outlined in this paper are primarily intended for use by product managers who are responsible for defining new, or enhancing existing, products and services. Based on practices and examples from software application development with distributed development teams, these practice principles can also be applied to almost any type of product development, whether commercial products or internal-use applications. Also they can be useful for business analysts who are responsible for defining internal use business applications, as well as for small, independent development teams that need to clarify objectives.

Product Requirements Development Tools

The following is a listing of discovery and development tools to create and refine product requirements during the product development life cycle (PDLC) scoping phase, which ideally would occur prior to a formal team project initiation.

1. Context Diagram

The context diagram provides an easy to understand, visual representation of the major interfacing entities and product users. In the center, a square represents the complete solution to be addressed by the project, and within it are the listed the main high-level, functional additions and changes. The external entities and users are then shown with arrows depicting interface actions and activities.

These simple diagrams can be created with most computer drawing applications or Microsoft Visio using the Basic Shapes and UML Use Case stencils.

The context diagram can then be reused as a helpful summary figure in the product requirements document (PRD) as a starting figure for product use cases (see tool section below) and software user access permissions matrixes.

Context diagram example

Exhibit 1 – Context diagram example

2. Product Flow Diagrams

Flow diagrams can be extremely important in helping discover product requirements and in ensuring that contributors are discussing and considering the same things. Oftentimes, different people can be discussing a process but not realize that their own internalized versions differ. Also, some processes might be overly complicated and should first be optimized before attempting to automate.

The following is a list of processes (for both people and systems) that should be diagrammed to help validate workflows and identify needed areas of improvement:

  • Current process workflow mapping (without the new solution);
  • Proposed new processes;
  • New solution client implementation processes (setup, installation, configuration);
  • Maintenance processes (anticipated updates and changes).

Initial versions should be created by the product manager to help research and gather product requirements, and then they can be updated and improved in further phases with cross-functional reviews. Microsoft Visio business and cross-functional flowchart stencils are easy to use tools to create and develop these flow diagrams.

Product Flow Diagram Example

Exhibit 2 – Product Flow Diagram Example

3. Product Prototypes and Mockups

A picture can be worth a thousand words, and so creating sketches of what the product manager and others have in mind is an invaluable tool that can improve product requirement definitions and facilitate eventual design efforts. The product prototypes created by the product manager are not intended to be used to force the actual design toward a given solution since there may be better alternatives that the design team will create in later phases. Instead, the primary purpose is to help the product manager clarify his or her own understanding and help discuss needs and potential preliminary solutions with stakeholders. However, there are times when there might be a need to be specific, such as when the layout and content are needed for certain types of product reports or on-screen information, and those would be more accurately referred to as “mockups.”

These prototypes and mockups are not intended to require anyone else with specialized skills to create them because that would involve additional resources prior to the actual project initiation. The product manager should only use simple tools and methods which they are already proficient in using and not try to overcomplicate things by attempting to learn new software applications. They should only use tools that they either already have access to or can acquire and use without significant investment and training.

To create computer screen prototypes, the following methods can be use:

  • Microsoft Word document that lists user input fields (whether they are required or not and in acceptable formats) and resulting output fields (see example below);
  • Microsoft Excel;
  • Scanned images of hand drawn concepts;
  • Marked up screenshots of existing application screens using MS Paint;
  • Microsoft Visio software and database and Windows UI stencils.
Prototype example simple MS Word

Exhibit 3 – Prototype example simple MS Word

For web applications pages, Microsoft Office SharePoint Designer can be used, or there are some simple online web design tools that can be used.

Prototype example simple HTML

Exhibit 4 – Prototype example simple HTML

For communication mockups (such as letters, emails, faxes, reports, etc.), Microsoft Word or Excel can be used to show layout and define data fields.

4. Product Use Cases [User Scenarios]

Product use cases provide clarification regarding how a product manager would envision users and external systems interacting with the proposed new product. Since the actual design would not have been created yet at this point, the product use cases may be vague in places, but the intent is to use them as a starting point to discover potential design considerations and product requirements. This can be especially useful in identifying any required decision logic and processing path alternatives, giving the product manager time to investigate and define details that may be needed before a funded project clock is counting down. Then in the project estimation and planning phases, these product use cases are valuable helping evaluate development and testing efforts.

Product use case documents usually contain the following information:

  • Context diagram: Derived from the product context diagram, this version only shows the users/entities and interactions for the particular scenarios in the document.
  • Description: Clarifies the intended goal to be achieved by the scenario and product requirements for cross-references.
  • Actors/Entities: Lists the users and external systems (actors and entities) involved in use case.
  • Assumptions: Specifies the prerequisite conditions that must be true for the use case to terminate successfully.
  • Steps: Sequences the interactions between the actors and product system necessary to achieve the goals, and any variations in the steps.
  • Non-Functionals: Lists any non-functional requirements that the use case must meet.
  • Issues: Listing of any issues that remain that need to be resolved.
Product use case example

Exhibit 5 – Product use case example

5. Voice of the Customer (VoC) Validation

Once the product manager has completed what he or she feels is a workable set of requirements for the defined product, it is useful to do some research with target users to validate the definition, prioritization, and assumptions. This will help bolster the business case and will help stakeholders and project team members understand the prioritization for the scope selected requirements.

Research can easily be done with presentations of the prototypes and mockups to selected target customers, as well as also surveys to solicit feedback and attractiveness ratings.

This research should involve customers (those who will be making the financial decision to purchase the product), users (those who end up using the product on a regular basis), influencers (those who advise or support customers and users), and sales representatives (both direct and resellers).

Putting It All Together: The Product Requirements Development Process

So now that we have a core set of tools that can be used to help discover, define, and manage the product requirements, the question is, how can one use them most effectively in the PDLC scoping phases for a project request review and initiation approval? Each of these tools contains different levels of information, and the actual refinement of each is actually an iterative process as different aspects are considered and analyzed. For instance, initial requirements usually just consider the most obvious service processing path, but as the context diagram, process flows, and prototype/mockups are created, the need for revised or additional requirements becomes apparent.

Product requirements development process

Exhibit 6 – Product requirements development process

The Agile PLC Scoping Phase

The following is a suggested agile sprint outline approach that can be used to develop the project requirements. The objective for each element within the sprint is to have a good initial working draft that can then be used and refined in the subsequent sprints. Only in the final sprint are all of the useful tools completed so that they can be used for the official project review and approve and then used as input for project initiation and planning.

Sprint 1: Scope Definition

  1. New product project summary;
  2. High level requirements: Problem and purpose statements;
  3. Initial backlog and user stories;
  4. Functionality roadmap.

Sprint 2: Requirements Definition

  1. Context diagram;
  2. Process workflow diagrams.

Sprint 3: Requirements Validation

  1. Product use cases;
  2. Prototypes and mockups;
  3. Market research: Client presentation draft and feedback survey.

Sprint 4: Finalize and Approval

  • Requirements quality check;
  • PRD assembly, reviews, and approvals;
    • Ready to kick off design and development project;
    • PRD = Product project requirements backlog.

While requirements discovery and development efforts using these tools and process could take place within a project planning phase, overall project execution costs and execution time will be reduced if these are done beforehand. Also, there will be cases when it becomes apparent while going through this process that the initial assumptions regarding complexity and attractiveness of a project are disproved. This can lead to a whole new reconsideration of the intended project—without having had to commit project provisional resources and funding.


The tools in this paper are just a few of many different approaches that may be used. The use of some of these tools has been modified somewhat from their traditional use to make them easier to be used by, and communicated with, non-technical staff. Not all of the tools would be necessary or beneficial for every type of product or project. When deciding which to use, it is important to consider styles and level of required detail based on an organization's preferences and capability maturity. Teams should discuss existing preferences and then experiment with selected new methods to see which ones can help improve their overall projects’ performances. For new products and functionality, probably all of these tools used together would be relevant, whereas for simple, existing, product functional improvements, well-written and detailed product requirement descriptions would probably suffice.

Always keep in mind that process and quality improvement is a journey. Don't try to do everything and achieve perfection all at once. Try something, evaluate the results, and refine your approaches over multiple projects.

As the product manager, the more specific you can be regarding your requirements, the more likely it will be that you will get what you, and thereby your customers, want.

© 2014, Robert Grupe
Published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA



Related Content