We all know the phrase, "Diamonds are a girl's best friend," right? Maybe it conjures images of Marilyn Monroe in Gentlemen Prefer Blondes
, but what does it have to do with business requirements?
The perfect diamond has specific qualities, or what experts call the 4 Cs (cut, color, clarity, and carat). For me, as an IT project manager at GovWebworks, this parallels something else dear to my heart. My own version of the 4 Cs (complete, compliant, clear, and concise) has become my best friend when compiling project requirements.
Why are business requirements important? When I'm in the role of product owner, I'm passionate about helping our clients solve business problems and implement solutions that really help people. However, I can't just ask, "What do you want the system to do?" and expect that the answer will be clear enough to design and develop a solution to meet their needs. I must first gain an understanding of the overall requirements of the project:
- What's the business problem?
- What results would an effective solution deliver?
- What is the value of the solution to your organization?
It's important to remember (as cliché as it might sound) that business requirements will make or break a project. We work on many fixed-bid projects in the public sector, and they are destined to fail or go over budget if business requirements are not properly captured.
Here are some of the potential cascading problems that can arise when overall goals and requirements are unclear:
- The wrong features are built, and the business problem isn't solved: Wait, I can't edit content on this web application you built for me?
- Money and time are wasted, and the business may not get the opportunity to solve the whole business problem: We already spent all of our budget for this fiscal year.
- Trust and reputations are harmed, the project team loses momentum, and confidence in their ability to deliver results is diminished: We can't deliver services with this product in the way we need. You're fired!
I find the best way to head off these issues early is through the process of gathering crystal-clear business requirements.
The 4 Cs of business requirements
How do you know you have documented the perfect requirements? I like to check against the following 4 Cs.
Carat is the unit of weight for diamonds. The more carats, the more valuable the diamond. With requirements, too, the more weight (in terms of details) they have, the more valuable they are. That's why I always strive to make them as complete as possible, including both explicit and implicit needs. Explicit requirements are the easy ones. These are detailed in the RFP, in discovery sessions, over email, etc., and expressed through existing documentation. Implicit requirements, on the other hand, are more difficult to capture. These may not be told to you directly. Stakeholders either assume you already know or they can't imagine an alternative process. Complete requirements are best realized and captured as you work on user stories with business stakeholders and your team. During the process of walking through business problems, I learn about the hidden requirements necessary to design the best solution.
As Henry Ford is believed to have said, "If I'd asked people what they wanted, they would've said faster horses." To avoid delivering just a faster horse, it's up to me as the product owner to draw out the other possibilities from stakeholders, and see them articulated in the requirements. This helps ensure the best final solution.
Failure to capture complete requirements can have serious impacts on the design and development of your solution. At best, it means rework or delays in the schedule to accommodate scope changes. At worst, it's a missed opportunity to deliver meaningful improvement.
"The user will be able to log into the application."
"The user will be able to log into the application using credentials managed in SAP, where the users' roles and permissions are established. The same roles and permissions are required for this application."
Diamond color actually refers to lack of color, with the most colorless being the highest in quality and value. Perhaps the more colorless (thus valuable) characteristic of perfect business requirements is that they be compliant. Compliant requirements adhere to state and federal regulations — HIPAA, FERPA, NIST, Section 508, WCAG, etc. These are the privacy, accessibility, and standardization rules necessary to protect and serve the constituents. They are usually an essential part of the final solution.
To ensure compliance, we strive to educate ourselves around the particular requirements regulating the agency and project. I also document organizational standards and other internal policies and procedures that may not be dictated by regulation. Your own subject matter experts may already have this knowledge, but where it is lacking, we can fill in the gaps.
Obviously it's vital to ensure that you have captured all the requirements in relation to compliance, since noncompliance can result, at a minimum, in expensive rework (or even project termination) and, worse, in data loss, fines, and legal action.
"The web application must be tested for accessibility."
"The web application must be tested for accessibility standards Section 508 and WCAG 2.0 and WCAG 1.0 for web-based Intranet and Internet information and applications."
Clarity is an important C for diamonds in reference to the presence or absence of blemishes (surface flaws) and inclusions (internal flaws). Clarity in business requirements is equally valuable. Requirements should be flawless and in no way ambiguous to your design, development, and quality assurance teams.
Equally, client stakeholders must be able to comprehend the requirements, since their approval and sign-off is critical. Document the work flow and functionality, as well as any assumptions. Project collaboration tools, such as Confluence
, are great for this purpose. They help us store all the project documents in one place: versioned and complemented with a project glossary, wire frame documents, design files, or any other artifact delivered by the project team.
Agile projects value working software over comprehensive documentation, but there is still a need for the project team to know what to build and why. The key is to avoid analysis paralysis. Once the requirements are clear, the team can begin proving them out with incremental software builds and proofs of concept.
While Agile projects welcome change, clear business requirements are still needed to help stakeholders evaluate and prioritize the backlog.
"The user must be able to access all the reports."
"The administration user must be able to access the reports page from the primary navigation menu on the web application."
The cut of a diamond is the work of the gem smith, who hews away the flaws to leave a perfect stone behind. Business requirements benefit from the same refinement process, making them more valuable. Leave out words that don't add to the understanding of the requirement. Should
, and could
are too passive. Don't use them. Shall
, or must
are better choices. Pick one, and stick to it.
Substance is also important. Examples, metaphors, or analogies of what you think you are trying to express are not necessary; they only cloud understanding and interfere with the clear C. I also suggest leaving out any words that point toward motivation or bias. "Just the facts, ma'am!"
Concise requirements help project teams understand the meaning and value of the solution. Quality assurance and user acceptance teams will also thank you, since concise requirements make test cases much easier to write, create, and execute.
"When a user searches for something on the website, it should narrow down choices when the user selects from those little check boxes on the left-hand side that say words that help the user find what they are looking for. I like those. Let's use that. It's kinda like when you are shopping, and trying to find something in your size. Yes, that."
"The search functionality shall use faceted search to help users refine search results."
Project success relies on getting as close to perfection as possible with our business requirements. When we keep the 4 Cs front of mind, we find that:
- The project is delivered on time and on budget; sighs of relief all around!
- Business needs are met, and regulatory and compliance boxes are checked.
- The right product is built and real value is delivered because end users' needs are more clearly incorporated into the solution.
As Marilyn might have sung (if she'd used my 4 Cs), "Square-cut or pear-shaped, these reqs don't lose their shape . . . "
I hope you find them useful and that, with a little polish, they can help your projects (and teams) shine.
Do you have your own approach to business requirements? Let us know in the comments!