When you are developing initial requirements for a new software product development project, you may find yourself questioning the appropriate level of detail to provide for specifications.
You may feel compelled to provide a high degree of specificity so the development team can create an accurate estimate of cost and time to build the defined solution. You may feel worried that if you miss something in the software requirements, the project — or even you — may be viewed as a failure. The good news is that you can loosen up! There is a better way to develop requirements, and it doesn’t include specifying every detail at the start of the project.
Detailed Specifications – Too Much Definition, Too Soon
The first step is to realize you probably should not be creating a detailed set of functional or technical specifications for a development team to build. It’s usually too early to focus on detailed specifications before the development team has an opportunity to creatively engage in the project at a broader level — including business and user motivations. Providing detailed functional and technical specifications too early can create a false sense that the problem or opportunity is completely understood, which can result in missed opportunities or inaccurate project plans.
I suggest you view your requirements development task from the perspective of defining a design project and allow the team you’re engaging to collaboratively design a solution and incrementally refine functional and technical requirements with you as the high-level product design matures. By defining your requirements from the perspective of a design project, you shift the focus from detailed functional and technical solution specifications to high-level descriptions of problems that need to be solved, opportunities to pursue, or stories that exemplify users interacting with your product.
An experienced poly-skilled team can take such a high-level requirements document and estimate a ballpark budget that allows for finding success (sometimes a shorter exploratory, collaborative, design engagement may be needed to validate the ballpark budget and refine scope). You’re not getting your money’s worth by handing a talented team detailed specifications on what to build. You’ll gain more value from collaboratively defining the detailed product specifications as the project progresses.
So how do you define requirements from the perspective of a design project? Good design methods focus on the people you are solving problems for and the contexts of interaction with your product. Good design methods also focus on the economic viability and technical feasibility of a solution.
A Better Alternative
Good requirements documents will answer these questions.
1. What value are you creating?
Even though your specification should avoid the solution details, you should define a high-level vision for your product that will allow a development team to quickly understand the value your product will provide. An elevator pitch is a great way to concisely convey the problem statement, value proposition, and differentiating characteristics related to your product. I really like Roland Smart’s elevator pitch template as outlined in example #2 of his elevator pitch exercise blog post.
2. Who is going to use your product?
Describe the variety of people you are solving problems for, outlining their behavior and how they will interact with your product. Consider:
- Primary Users: Who uses the product the most or gets the most value from the product? Keep in mind there may be multiple primary users.
- Secondary Users & Affected People: Who uses the product less than the majority of people but may use a subset of features? Who is affected by the product (could be someone else in the home or work environment)?
- Internal Users: Who will support or administer the product?
3. What problems does your product solve?
Describe the problems your product will solve for the primary, secondary, affected, and internal users:
- What problems do your intended users currently have?
- How are they currently solving their problem?
- What are their aspirations or goals?
- What are their actual behaviors related to their needs and goals?
4. Where and how do you believe your product be used?
For each type of user, write brief stories outlining key interactions of them engaging with your product:
- Create simple text-based bulleted list stories that identify context (Where are they?) and engagement points (When and how do they use the product?).
- Write the stories at multiple levels of zoom (Where is the user? Who else is around? Are they likely to get interrupted or distracted? What are the time constraints? What environmental factors are important to consider?)
- Don’t allow the scenarios to focus on specifying details about the product’s features. Stay out of user interface requirements or specifically defining how features work. Don’t even get close to engineering specifications like technology choices or performance characteristics.
5. What is the business case for creating your product?
Describe the business opportunity, goals, and constraints. Identify:
- A sensible budget to allocate to the project (internal case building should first identify the size of the opportunity and then identify a sensible budget to pursue the opportunity).
- Constraints like time, budget, technology, business or IT processes, and human resources.
- Business stakeholders and the expectations and forces they are working under.
- Financial goals and success metrics or customer behavior metrics that correlate to business success.
Conclusion
By identifying the perceived needs of your user and the constraints related to viability, a talented team can collaboratively work with you to design and implement a solution that optimizes for desirability, viability, and feasibility. You and your team can also refine and document specific product requirements along they way.