Business Analysis For Dummies
Book image
Explore Book Buy On Amazon

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.

About This Article

This article is from the book:

About the book authors:

Paul Mulvey, CBAP, Director, Client Solutions, B2T Training, has been involved in business analysis since 1995. Kate McGoey, Director, Client Solutions, B2T Training, has more than 20 years' experience in application development and life cycle processes business. Kupe Kupersmith, CBAP, President of B2T Training, possesses more than 14 years of experience in software systems development. He serves as a mentor for business analysis professionals.

This article can be found in the category: