We ran a series called Writing Good Requirements – The Big Ten Rules in May 2006. Bloggers are notorious for not being able to count. We had ten rules at the time, and now we’re adding an eleventh. Writing Correct Requirements may have been the unwritten rule, but now we take a look at it.
Background
The original series started with a summary of the ten rules to writing good requirements, and then we followed up with ten articles with details of each rule. And now we add another one – writing correct requirements.
The Big Ten Eleven Rules of Writing Requirements
- Valuable
- Concise
- Design Free
- Attainable
- Complete
- Consistent
- Unambiguous
- Verifiable
- Atomic
- Passionate
- Correct
Correct Requirements
Correctness in requirements is simply about getting it right. We wrote previously about how to apply use cases to creating correct requirements. Writing requirements correctly is as much about getting accurate information as it is about accurately documenting the information we gather.
Correctness applies in a context. “Are these the right requirements to achieve goal X?” Verification is the process of verifying that we identified the right requirements to achieve a particular goal. Validation, on the other hand is the process of assessing requirement completeness. People often swap these terms as being nearly synonymous.
Verification Techniques
To verify that requirements are correct, we start by asking two simple questions. Here’s an example for writing a software requirements specification. Set aside for the moment that some people consider this to be design, although from a developer’s perspective, it is a specification (or requirement). This serves as a good example for business analysts.
- Does each of these requirements contribute to achieving our goal? If a requirement does not help us achieve the goal that it supports (in a structured requirements framework), it is not a correct requirement. Either the requirement is placed under the wrong goal, or it truly doesn’t belong.
- Can our goal be achieved without these requirements? If our goal can be achieved without the requirement, then it isn’t required. “The system shall generate a report of all outstanding customer bills” is a requirement. If the goal is “Identify a customer’s unpaid bills”, then “The system shall display any unpaid bills for a customer” is a more correct requirement, because the goal can be achieved without a report.
A market requirement (useful to product managers) would be “Reduce the cost of accounts payable by 5%.” There is an ideation step in going from documenting market requirements to documenting product requirements. In that step, a product manager will decide how to approach, with her product, the reduction of accounts payable. Consider the following approaches and requirements and their hypothetical correctness verification.
- Approach: Remind customers of outstanding bills. Requirement: “The system shall generate past-due notices for all bills on the monthly anniversary of each bill.” This requirement would not be correct if bills are issued with 90-day terms, because the bills are only due, not past-due. We identify that this requirement is incorrect because of the semantics of past-due billing, and the hidden complexity of varying billing terms.
- Approach: Relax outstanding debt by 5%. Requirement:” The system shall reduce the outstanding balance of all past-due accounts by 5%.” This requirement would reduce accounts payable amounts, but it would not address the opportunity cost of the missing funds. Companies earn interest on credit balances, and pay them on debts. By decreasing the amount owed, a company would not have any impact on the amount that it could have earned (or avoided paying) in interest. This does reduce the size of the accounts payable amount, it does not achieve the goal.
- Approach: Increase prices for high-risk customers. Requirement: “The system shall adjust product prices per [referenced actuarial table], to reflect the risk of late payment.” This would not reduce the cost of accounts payable, although it might increase the profitability of the product (and might not). Since this doesn’t directly contribute to achieving the goal, the requirement is incorrect.
Context
As the examples highlight, we have to understand how the market requirement works. A knowledge of the billing rules for our customers, as well as an understanding of the cost of capital are both required.
Conclusion
Writing good requirements demands that the requirements be correct. Correctness can only be identified with context and domain understanding. Correctness can be determined by asking if a requirement achieves the goal, and is required to achieve the goal.
“Can our goal be achieved without these requirements? If our goal can be achieved without the requirement, then it isn’t required. ‘The system shall generate a report of all outstanding customer bills’ is a requirement. If the goal is ‘Identify a customer’s unpaid bills’, then ‘The system shall display any unpaid bills for a customer’ is a more correct requirement, because the goal can be achieved without a report.”
If the alleged requirement does anything more than state the goal, it is always logically possible to satisfy the goal in another way. Yet if it is possible to achieve the goal without the alleged requirement, it isn’t a requirement. Therefore, the requirement isn’t something that achieves the goal, it is goal.
(We could get into dicey issues about nomological and other forms of possibility, but I think the practical conclusion will end up being the same.)
That’s why I define “requirement” as the least stringent condition that must hold to solve or avoid a prospect problem. The goal is to solve or avoid the problem. Nothing more. The goal is the requirement.
I like this comprehensive and well detailed overview (almost specification) of the required characteristics of requirements. This is very helpful.
The problem that I encounter a lot in my experiemce as a SW PM is that the people who need to write the SRS are not at all skilled at it. It is a struggle to even get them committed to do it and when they do, the quality is usually poor.
I found it useful to work with them in 2 stages: 1. Start with something minimal. 2. Evolve the doc over time to a full, formal spec. For this 2nd part, your article is very useful and I will direct my team members to it.
I have just written about this topic is my blog: (http://mosgot.blogspot.com/2006/11/software-requirements-specification-is.html).
Thank you.
Moshe,
Thanks very much for reading and commenting!
I think your idea, get something, then make it good, is a good one. I think the dynamic that affects writers with a blank sheet of paper is the same one that affects people new to writing requirements / specs. More experienced people can immediately start jotting down an outline that captures elements of the SRS and then fill it out. “Getting started” can definitely be overwhelming for folks who are less comfortable writing specs.
A question – when scheduling the activities of the rest of the team, specifically the implementation team and other stakeholders of the SRS – do you get them started on the “something” version, allowing them to work in parallel with the revision/improvement of the SRS? Or do you wait until there SRS is “ready?” Or something in between?
Thanks again,
Scott
Scott,
In answer to your question, yes, it is possible that the implementation team will start implemetation while the first version is being written.
The most important thing here is to manage the inherent risk in this approach, namely, that the engineers will implement something that will later conflict with the SRS. To minimize the risk, I try to do the following:
* Make sure that writing of the SRS is not delayed because everybody is “busy implementing”. In other words, although implementation starts while the SRS is still being written, the SRS is the higher priority, not the other way around. This ensures that the SRS will become available ASAP, hopefully before the engineers have moved to far ahead.
* Make sure that the implementors are closely involved with the SRS development from the start. That is, the engineers participate in the development of the SRS. This way they know early on what the SRS is going to say so that they already know what to implement even though the SRS is not yet “released”.
Cheers.
Hey Moshe, thanks for replying!
Sounds like a good approach. I’ve been on a couple projects where the “our dev team is idle” pressure continues to bear down on the requirements team. It would have been great to have a PM on that project who served to keep the prioritization as you have.
Having the implementation team “in the loop” about the SRS definitely helps too, and allows people to get started. It introduces a risk, but that risk is easily mitigated with either experienced developers/testers, or coaching from someone experienced. In my experience, it has only been an issue when folks were brand new (“But the spec used to say….
How do you keep the implementation team informed on the doc as it is under development? I’ve seen a few different approaches:
I believe any team can make any of the approaches work, but with tradeoffs. I’d like to have a collaborative online/offline available solution, with RSS updates to stakeholders (instead of “hey, I updated this” emails) and integrated approvals. Anyone know of something that has all of that?
Thanks again,
Scott
I think the tool that ends-up being used is very much dependent on the specific circumstances of the project/company: What is available; What is already being used; How willing is the company to migrate to another tool; Big vs. Small company. Startup vs. established, etc.
The ideal tool that you describe sure sounds like the right one. I am not aware of such a tool and will be interetsed to learn if one exists. But I do want to emphasize that, IMHO, the tool alone is not enough – not even your ideal tool. Two more major factors must be taken care of:
1. Put the right process around the tool. Without the process, the tool will be used in an uncontrolled way, resulting in chaos.
2. Get all team memebers into the habit of using the tool routinely according to the process. Without that, the beautiful tool will be there to collect dust…
Completely agree. Yes. Agree some more. :)
I was curious what tools you’ve used. I’ve used all but #5 on different projects with different companies. And from my experience too, something like #5 would be ideal. Also completely agree about process approach, and would add that even if all companies used that magic tool, each team/company would need a different process.
I don’t know of a solution that has all the elements of #5 either. I’m hoping someone will chime in… I don’t have time to build it at the moment.