One of the major issues plaguing information technology projects is that the solution that gets built does not actually solve the business problem or opportunity. This is often because the software requirements are too high level to effectively guide the technical team towards a successful implementation or are disconnected from the business needs and desired outcome, and solve the wrong problem.
In this video, we’re going to dig into the different ways to analyze software requirements.
Software Requirements: Defined
Software requirements describe capabilities a solution must have and information the solution will manage. Software requirements are where business meets technology. They need to be described in ways that business users understand and technical stakeholders can use to build what the business actually wants.
Well done software requirements work is not just well-written requirements. It’s about ensuring the requirements are are implementable by the technology team – but also that they realize what delivers actual value to the business. Collaboration, validation, and buy-in, using language that everyone can understand, are just as important as syntax and formats.
Historically, in traditional waterfall methodologies, software requirements were specified in a Functional Requirements Specification (FRS) or Software Requirements Specification (SRS) in long categorized lists. They are also often a significant component of a Business Requirements Document (BRD).
Different Templates You Can Use
Today, software requirements are more often captured in user stories, organized in product backlogs. Sometimes they are analyzed in use cases. Although it’s not uncommon for a team to embed a backlog in a BRD, which gets completed upfront, and then manage that backlog in an agile way throughout the implementation.
FRSs, SRSs, BRDs, backlogs, user stories, and use cases are all different containers for the software requirements. The choice you make about the container will often be driven by the practices in place within your organization or team. The systems-thinking and collaboration skills you cultivate to discover, analyze, and validate the software requirements transcend any specific template or container, and are the primary focus of what we teach at Bridging the Gap.
Examples of Software Requirements
Let’s take a look at a few different examples of software requirements.
Typically in an FRS, SRS, or BRD, the software requirements will be captured as lists in system-shall statements. For example:
“The system shall stream a live audio session.”
A user story in a product backlog adds more context:
“As a course participant, I want to stream a live audio session so I can listen to a course lesson on-the-go.”
Learn more about user stories in this tutorial:
A use case, on the other hand, would present this requirement as a series of user actions and system steps. For example:
- The course participant selects to listen to the audio presentation.
- The course delivery system presents an audio file to the participant’s web session.
Learn more about use cases in this tutorial:
A user interface model is a visual representation of how the software could look, when built and presented to an end user.
Learn more about wireframes in this tutorial:
Pros and Cons of Different Requirements Documents
Each of these software requirements approaches has pros and cons, and each can work successfully.
- System shall statements provide a clear, easy-to-read and sort list of functional requirements, which can be very useful for evaluations and traceability. But they tend to lack context and specificity.
- User stories embed the business objectives into the software requirements, ensuring the team pays attention to not just what the system needs to do, but why that feature is importa They are also a great planning tool, allowing teams to prioritize work at a low level of granularity and respond to change more efficiently. However, in a large backlog it’s easy to lose track of the big picture and, on their own, they do not support your analytical thinking.
- A use case is a robust analytical tool that encourages strong systems-thinking and supports collaboration between business and technology stakeholders. However, use cases can easily get bloated with complexity and extra scope and, the path from use case to implementation can be difficult to manage successfully.
- A user interface model is easy-to-understand, generates insightful feedback, and can help teams get clear on the software requirements quickly. They are a great complement to any of the above. However, on their own, they can lack specificity and can lead to false assumptions.
If you’d like to see what a use case looks like, I offer a free template as part of the BA Deliverables Collection.
Learning to think in use cases helps you explain what the software needs to do using language that business users can understand. They also tend to miss fewer requirements. Meanwhile, your stakeholders see the full potential of the solution and provide clarifying feedback in more efficient ways.
No matter what container or analytical tools you choose, functional requirements are not technical design. You do not have to know how to write requirements for software. In fact, those with a technical background must learn how to craft requirements in clear language that a business user can understand, and resist any temptation to include pseudocode or technical details.
Want to learn more? Watch this video next:
Learn how to analyze software requirements in The Business Analyst Blueprint training program
If you’d like to go deeper with me, I teach these concepts in depth inside The Business Analyst Blueprint training program.
We have conversations about what problem we’re solving, how to flex our skills on different types of team, and how to leverage AI as part of the proces. And I’d love to work with you or your organization to help you and your business analysis practice get better.