Businessman Bob has a business problem that requires a software solution. He reached out to Developer Dan to tell him about his problem and ask how much a solution will cost. Developer Dan explains the complexities of pricing software projects and recommends that they start the process by gathering software project requirements to establish the project scope and create a project estimate.
Bob agrees and is introduced to Business Analyst (BA) Ann. She is going to work closely with Businessman Bob, his team, and Developer Dan’s team to gather the requirements for the project.
There are three types of requirements BA Ann will be working to gather:
Business Requirements
This set of requirements is the most important. They communicate the project vision and business benefit.
The project vision details how the project deliverable will solve a specific business problem or set of problems. Successful software projects start with a clearly defined project vision.
The business benefit of the project should also be established. There are two essential questions to ask:
- How will this product generate revenue or reduce costs?
- By how much and when?
The answers to these questions will determine the potential value to your organization. For example, if you are working on a revenue-generating product, development costs of $250,000 seem reasonable in the light of $1M revenue projections.
On the flip side, does it make sense to spend $100K on a project that will save $50K? Probably not.
Until the project vision and business benefit have been established by the project stakeholders, working to gather user and functional requirements is a waste of time. It is impossible to fully understand the needs of the user and the functional elements of the project until the business requirements have been established.
User Requirements
Businessman Bob is not the person who will be using the software and is not the best person to ask about user requirements. BA Ann will work with Businessman Bob to identify user groups. Once user groups have been identified, she will begin collaborating with multiple users to learn what they need the software to do.
The key to gathering user requirements is asking the right questions to the right people. The goal of this process is to get the voice of the user as close to the development team as possible.
Developers are not mind readers.
The only way development teams can engineer software that meets the needs of the users is if users tell them precisely what they want. What makes this so tricky is that users often don’t know what they want, and sometimes what they want does not align with the need established by the business requirements.
This is where a skilled business analyst can make a huge impact. They know how to collaborate efficiently with users to identify the functionality they desire and how it aligns with the business requirements.
When discrepancies arise between user wants and business requirements, the business analyst will collaborate with the product owner (Businessman Bob) to determine if modifications to the business requirements are necessary.
Functional Requirements
The final set of requirements are functional elements. In general, these requirements indicate what conditions are required in varying circumstances for allowing users to perform tasks that align with the business requirements.
For example, the software being created for Businessman Bob has an accounting module requirement. A functional requirement dictates that when Accountant Allison enters a payment, the entry field must display the number in a dollar currency format with four digits after the decimal point.
Why four digits after the decimal point? This company manufactures widgets that are priced at fractions of a cent when sold in bulk.
Without this level of detail provided with functional requirements, there is no way for the developer to know how to create vital elements of the software to allow the users to effectively use the software to achieve the business vision.
Project Requirements and Agile Development
The Agile method of building software delivers small iterations at quick intervals. The objective is to provide users functional software that adds value as soon as possible. Each iteration gives users with an opportunity to use the software and provide feedback.
Agile also gives users and product owners the benefit of a continuous feedback loop during the development process. As a result, project requirements are likely to evolve as the projects progress.
It is impossible to think of everything at the beginning of the project. Functionality not considered during the initial requirements gathering is likely to be revealed. This is expected and a regular part of the Agile process.
When this happens, BA Ann will collaborate with the project stakeholders, including Businessman Bob, to determine if the new requirements should be added to the project scope, create an estimate, and timeline.
To ensure you experience the ROI you want, good facilitation and communication is a must. For a free checklist and infographic to help guide your planning, send an email to bizdev@level12.io
Read the next blog post in the Software Project Requirements series: Business Objectives for Software Projects.