Solution requirements in a business analysis specify the conditions and capabilities a solution has to have in order to meet the need or solve the problem and provide clarity around delivery needs. They don’t define how the solution will solve the problem technically or specifically; that happens later. Solution requirements must meet or support the driving project and business objectives, in addition to meeting stakeholder objectives.
When developing solutions or solution concepts, stakeholders commonly focus first on identifying and writing software requirements and worry about the rest of the requirements later.
But doing that without really knowing which features or functions will be most valuable in meeting the business and stakeholder requirements means your team may end up building some cool stuff without actually solving any important problem. You can’t really be sure what capabilities will be truly valuable until the overarching solution vision is clear.
People get excited by technology or by finding great opportunities to improve. At this stage, beginning to brainstorm approaches or evaluate how something may be done or designed is very easy. Don’t let that happen! Instead, brainstorm about what the solution has to achieve for stakeholders before everyone gets caught up in the details of how to build it.
How to use a vision statement to define the solution in a business analysis
A vision statement articulates and defines the holistic need for the solution. It’s the most important of all the solution requirements. The vision specifies which conditions and capabilities are critically required for the solution to effectively meet needs and deliver value.
Developing a clear vision enables you and the stakeholders to focus on identifying requirements for what stakeholders need first, without inadvertently going too far down a single solution option path.
Because many options are often available for solving a problem, you want to be sure to focus discussions on solution outcomes, results, and what-nexts and gain agreement first on what the solution has to support or enable. Without agreement on the overall vision, the requirements will end up just being a collection of stuff delivered without a solution delivered.
How to break your solution requirements into categories in a business analysis
After you’ve got a vision, you can venture into breaking the solution requirements down into two different categories: functional requirements and nonfunctional requirements.
Functional requirements: Functional requirements define the specific behaviors, responses, information, rules, or operations of a solution. They outline
What functions or functionality the solution will support
What specific stakeholders will do or experience while being a part of or using the solution
What information or data will be managed
Under what circumstances the behaviors and responses happen (or not) in order to ensure the required results and outcome
Although functional requirements are usually specified in the context of software and technical system capabilities, manual solutions also have functional requirements.
Nonfunctional requirements: Nonfunctional requirements specify the manner or the environment in which a solution is intended to operate. They describe the qualities a solution must possess and any supplemental expectations or conditions it must meet support. They define standards for
Usability: How easy the solution must be to understand or figure out
Reliability: To what extent users can rely on the solution to be accessible and work when needed
Performance: How quickly and efficiently the solution works and how it responds to commands and requests for action
Security: The level of protection the system and its data are expected to have in place
Design: The visual elements expected from the solution
Accessibility: The support that must be provided for users with disabilities, including hearing or vision loss, typically in compliance with relevant regulations such as the Americans with Disabilities Act of 1990
Documentation: The type and extent of written documentation expected or needed
Information capacity: Requirements for the amount of data or media to be stored, including the expected growth of the information over time
Information architecture: Any needs for the arrangement or organization of the information in the solution
Anything else: Whatever else the stakeholders decide is required of the solution
No matter what kind of solution requirements are identified and defined, those you elect to implement should be validated as capabilities that stakeholders really need and (as a result) decide must be included in the solution — either because including them is strategically, functionally, or technologically smart.
