Engineering teams often find themselves in situations where they have worked hard on delivering an important feature, only to find that what they have delivered is not what the business wanted. I understand the frustration!
The issue is often a gap between what the business said they required and what engineering understood and delivered. Too often, we hear engineers say, requirements weren’t very clear.
What is a software product requirement?
A software product requirement can be thought of as a composite of functional and non-functional requirements. Most software engineers understand that. Very few define them. Fewer consider them in the context of their business and customers.
Simply put, a requirement is a value you intended for your product to deliver to your customers.
In more mature organizations, business analysts and product owners are responsible for requirements. However, in a young startup, these roles aren’t often present formally. Often leading to chaos.
To maximize value from your engineering projects, it’s imperative that your team is working with highest quality requirements you can provide.
A well-described software requirement captures, at least these very important components:
Business Context in which the requirement is proposed or why are we building this?
Voice of the customer (or user) or who is the user and what do they want?
Non-functional requirements or aspects of the system that users will expect but might not explicitly mention.
A mini-framework for requirements
Considering a startup’s need for high velocity, the requirement framework needs to be effective and concise. However, to be usable, it must also be fairly complete. I propose a simple three step process:
Discuss
Define (and describe)
Test
Discuss
Open and clear communication is the key for any organization looking to reach its full potential. However, it’s of the essence, when change is involved. As requirements propose to change to your product, it is important to bring in key stakeholders and have them discuss their expectations from this change.
Suggested work-products:
Mind maps
Whiteboard sketches
Quick and dirty tech (if the source of the requirement is engineering)
Define
If it’s not defined, it’s not communicated. Define and describe your requirement in optimum detail. You will need this later when you are looking to validate your implementation.
Identify all the relevant people in(even outside your company) that have anything to offer in this process. Make them part of the project group.
Pro tip: Identify someone as a Product Champion. Someone who ‘gets’ what the product is all about.
Suggested work-products:
Product Vision:
This is where you outline the strategy for this product/requirement. How this requirement links up to the rest of your strategy. If this is a customer facing requirement, ensure this aligns with the rest of your marketing strategy. Similarly, if this affects other business functions, consider their goals before you detail out the rest of the requirements. This can be as detailed as you deem appropriate for your situation.)
User Stories/ Use Cases:
Whatever be your choice of process/practice, it is important to consider and outline how the end users will interact with your product.
Acceptance Criteria
For each user story, consider writing acceptance criteria. They can be used to identify when the user story is complete. Consider what externally visible behavior could ‘signal’ that the user story is implemented as required(at least, defined). Pro tip: Use something like Cucumber to include these as a part of your source tree. This serves as a living documentation.
Product Features:
As they are derived from the user stories above. This is what your engineering team could use as a list of things they need to implement. Even better is if they can come in and contribute on this list themselves.
Pro tip: Use a project portal/cloud folder to invite all your project members to so that they can have access to updated requirements all the time. Please avoid using emails, texts, phone calls as a way to communicate. It happens often for me to write this.
Test
Did you define what your business discussed? Is it sufficiently detailed for the needs of your engineering? Testing out your requirements before you build them out is important to avoid frustrating yourself and your business.
Float the requirements around in your project group, have them comment on the requirements, make necessary changes(quickly) and have a review meeting if necessary. I find for startups, meeting face to face(or on a conference call) is more efficient than endless email chains(duh!).
Summary
I will discuss specific techniques and tools for each of these steps and how they relate to different components of the requirement in a follow-up post. I hope you found this mini-framework useful and it’ll help you consider how you think about requirements at your start-up.
If you are struggling with requirements at your startup and would like me to help, please feel free to reach out: