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 the 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.
Suggested Read: Agile planning process and methods
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.
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).
Also Read: Agile team accountability
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 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.
For web application pages, Microsoft Office SharePoint Designer can be used, or there are some simple online web design tools that can be used.
For communication mockups (such as letters, emails, faxes, reports, etc.), Microsoft Word or Excel can be used to show layout and define data fields.
Also Read: Amplify agile with devops
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.
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).