Software Requirements Essentials
Distilled Requirements
Dr. Karl Wiegers has written ten books on software requirements, including two deep dives into developing requirements:
Software Requirements (with Joy Beatty), 672 pages
More About Software Requirements: Thorny Issues and Practical Advice, 381 pages
These books thoroughly cover requirements elicitation, analysis, and management in over 1,000 pages.
Dr. Wiegers recently teamed up with Candase Hokanson to write Software Requirements Essentials: Core Practices for Successful Business Analysis, distilling the requirements life-cycle to 207 pages. Ms. Hokanson adds an agile perspective to the book.
Essential Requirements Practices
Software Requirements Essentials introduces twenty essential requirements practices in five groups:
Laying the Foundation
1. Understand the problem before converging on a solution.
2. Define business objectives.
3. Define the solution’s boundaries.
4. Identify and characterize stakeholders.
5. Identify empowered decision-makers.
Requirements Elicitation
6. Understand what users need to do with the solution.
7. Identify events and responses.
8. Assess data concepts and relationships.
9. Elicit and evaluate quality attributes.
Requirements Analysis
10. Analyze requirements and requirement sets.
11. Create requirements models.
12. Create and evaluate prototypes.
13. Prioritize the requirements.
Requirements Specification
14. Write requirements in consistent ways.
15. Organize requirements in a structured fashion.
16. Identify and document business rules.
17. Create a glossary.
Requirements Validation
18. Review and test the requirements.
Requirements Management
19. Establish and manage requirements baselines.
20. Manage changes to requirements effectively.
Some of these practices may seem daunting to those who haven’t worked on large software development projects. A Salesforce admin creating a report or a simple flow doesn’t need to follow most practices. However, some practices are far more essential than others.
Practices Essential to All Projects
Practice 1. Understand the problem before converging on a solution.
So often, stakeholders start a project by discussing features without establishing what their organization needs. First, business stakeholders promote features to relieve pain points, while technical stakeholders feel more confident discussing features. While business analysts should capture and acknowledge pain points, they should also drill down to what the business needs from a solution.
Practice 3. Define the solution’s boundaries.
Even the smallest solution should have a scope, defining what it will and won’t do. Beyond that, the Software Requirements Essentials book asks additional boundary questions:
Which business processes, functions, and events will be part of the solution? Which ones will remain outside it?
Who will use or derive benefits from the solution? Who would it exclude?
Which software systems will be part of the solution? What will the interfaces between them look like?
The ultimate boundary defines “done” for the solution. It should cover the whole scope and nothing but the scope.
Practice 6. Understand what users need to do with the solution.
Karl Wiegers considers this the most important lesson he’s learned in fifty years of working on software development projects. It starts with Practice 1: Understanding the problem before converging on a solution. Elicit requirements that align with achieving business objectives rather than a solution specification.
Clarify boundaries (Practice 3) by exploring normal, alternative, and exception scenarios, .
Create user stories and use cases to specify how workers employ the solution to achieve their objectives.
Well-understood business and user requirements with well-defined boundaries contribute to a successful solution.
Practices Dependent on Project Size and Complexity
While all projects should employ Practices 1, 3, and 6, high-stakes development projects warrant more essential requirements practices, starting with well-defined business goals (Practice 2). These goals determine the objectives necessary to understand what users need to do.
When a project involves more than a few stakeholders, identify the stakeholders and key decision makers (Practices 4 and 5).
Create a glossary to ensure agreement on term definitions (Practice 17). Alignment on tem definitions reduces friction when assessing data concepts and relationships for a new data model (Practice 8).
Analyze, specify, and validate requirements for complex projects with many requirements.
Getting a Solution Right the First Time
Software Requirements Essentials: Core Practices for Successful Business Analysis introduces 20 requirements development practices in five groups:
Laying the Foundation, determining goals, and organizing stakeholders
Requirements Elicitation, understanding what stakeholders need from a solution
Requirements Analysis, ensuring requirements make sense and don’t conflict
Requirements Specification, specifying requirements terms and business rules
Requirements Management, organizing changes to requirements
Before eliciting requirements, stakeholders should at least understand the problem before discussing the solution, define the solution's boundaries, and comprehend what users need from the solution.
More extensive projects need to identify business objectives, stakeholders, and decision-makers. As requirements scale up, more discipline should apply to elicitation, analysis, and specification.
Software Requirements Essentials: Core Practices for Successful Business Analysis combines over fifty years of software requirements knowledge with a modern agile perspective to yield twenty essential practices for effective business analysis in software development projects.