The need for good requirements in our projects is essential, and there seems to be some misunderstanding about why. Although the Business Analyst (BA) elicits the requirements for our projects, I am including it in the Quality Assurance (QA) section because we work very close together in this space. And getting good requirements is critically important to achieving good testing.
In fact, it was so important to me that I decided to read the book, Mastering the Requirements Process: Getting Requirements Right 3rd Edition in order to better understand the requirement-gathering process. The first chapter was so captivating that I could not stop reading until I understood their methods for getting the results they claimed. The information that follows was taken from this first chapter and I am only highlighting the key points here, as it pertains to UConn. If you find this information intriguing, as I did, you can read the complete first chapter of the book here: Read Chapter 1.
The following notes were taken from the book for clarification:
When we say “he” in this book – usually referring to the business analyst – we mean “he or she.” We find it too clumsy to keep saying “he or she” or “he/she.” Believe us, requirements work belongs equally to both genders.
When we say “business,” “business problem,” or “work,” we mean whatever activity you are concerned with – be it commercial, scientific, embedded, government, military, or, indeed, any other kind of activity or service or consumer product.
The Essential Contribution of Requirements
“I know that’s what I asked for, but it’s not what I need!”
How many times have you heard that statement (or something similar) in a software project? The team has delivered exactly what the business stakeholders asked for, but it turns out not to solve their business problem. Why not? Because the real problem was never stated, and so was never correctly understood.
This is the major theme of these truths, and of this book. And this is also what first grabbed my attention and inspired me to read it. The authors’ unconventional (and somewhat genius) methods to accomplish this kept me reading. Although this appears to be talking about software products, it could just as well be any one of the many projects that provided solutions to the many areas of UConn in recent years, in the hopes that it would make people’s lives better.
As you read these truths, I ask that you think about them in terms of how they might apply to projects at UConn, both new and old. Think of that new Software as a Service (SaaS) or new application we are using that somebody decided would be best for everyone. Ask yourself, “Did we solve the real problem? Or did we miss the mark on this one.” We will review these questions again at the end.
The 11 Truths…
Truth 1
Requirements are not really about requirements.
The requirements activity is not principally about writing a requirements document. Instead, it focuses on understanding a business problem and providing a solution for it. Software is there to solve some kind of problem, as are hardware and services. The real art of requirements discovery is discovering the real problem. In essence, then, requirements are not about the written requirements as such, but rather an uncovering of the problem to be solved.
Truth 2
If we must build software, then it must be optimally valuable for its owner.
Note that we are concerned with the owner of the end result, and only indirectly the user. This focus seems to run contrary to the usual priorities, so we had best explain it.
The owner is the person or organization that pays for the software (or hardware or any other product you might be building). Either the owner pays for the development of the software, or he buys the software from someone else. The owner also pays for the disruption to his business that happens when the software is deployed. On the other side of the ledger, the owner gets a benefit from the software. To describe that relationship very simply, the owner is buying a benefit.
We could say that another way – the owner will not pay unless the product provides a benefit. This benefit usually comes in the shape of providing some capability that was not previously available or changing some business process to be faster or cheaper or more convenient. Naturally this benefit must provide a value to the owner that exceeds the cost of developing the product.
The role of the requirements discoverer – call him a “business analyst,” “requirements engineer,” “product owner,” “systems analyst,” or any other title – is to determine what the owner values. In some cases, providing a small system that solves a small problem provides sufficient benefit for the owner to consider it valuable. In other cases (perhaps many others), extending the system’s capabilities will provide a much greater value, and this can be achieved for a small additional cost. It all depends on what the owner values.
Truth 3
If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software.
Without knowing the requirements, there is little chance that any product emerging from a development project will be of much value. Apart from a few fortuitous accidents, no product has ever succeeded without prior understanding of its requirements.
It does not matter which kind of work the owner wishes to do, be it scientific, commercial, e-commerce, or social networking. Nor does it matter which programming language or development tools are used to construct the product. The development life cycle – whether agile, prototyping, spiral, the Rational Unified Process, or any other method – is irrelevant to the need for understanding the requirements.
This truth always emerges: You must come to the correct understanding of the requirements, and have your client agree with them, or your product or your project will be seriously deficient.
Truth 4
There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.
We build a lot of software. Tens (if not hundreds) of millions of lines of code are produced each year. Much of this output contains errors, and most of those are errors of requirements. As a consequence, a lot of the world’s software simply does not solve the correct problem.
And at the risk of repeating ourselves, we cannot stress enough that software is there to solve a business problem. Clearly, then, any development effort must start with the problem, and not with a perceived solution.
Truth 5
The requirements do not have to be written, but they have to become known to the builders.
Whether the requirements are written or not is beside the point. In some cases, it is more effective to verbally communicate requirements; in other cases, there is an inescapable need for a permanent record of the requirements.
However, it is not feasible to communicate all requirements verbally. The act of writing a requirement helps both the business analyst and the stakeholder to completely understand it. And a correctly written requirement provides trace documentation.
Note: To put it another way, if the business analyst cannot correctly write the requirement, he has not yet understood it. For this reason, and the fact that the requirements provide input to other functions within the PMO, we will be using written requirements for most of the projects at UConn.
Requirements are not meant to place an extra burden on the project, so nothing should be written unless there is a clear need for it.
Truth 6
Your customer won’t always give you the right answer. Sometimes it is impossible for the customer to know what is right, and sometimes he just doesn’t know what he needs.
The requirements activity is traditionally seen as somewhat akin to the task of a stenographer. That is, the business analyst listens carefully to the stakeholders, records precisely whatever it is they say, and translates their requests into requirements for the product.
The flaw in this approach is that it does not consider the difficulty stakeholders have when they are trying to describe what they need. It is no simple task to envisage a product that will solve a problem, particularly when the problem is not always completely understood.
Truth 7
Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.
These processes are not lockstep procedures where one mindlessly follows every instruction without question, in the prescribed sequence, and without variation. Instead, orderly processes comprise a set of tasks that achieve the intended result, but leave the order, emphasis, and degree of application to the person or team using the process.
Note: I can say that the processes described in this book are unique and are not yet mastered or used by the PMO. But if they were, I believe they would be a valuable service.
Truth 8
You can be as iterative as you want, but you still need to understand what the business needs.
Iterative development methods have become much more popular. This is certainly a worthwhile advance, but like many advances these techniques are sometimes overhyped. For example, we have heard people say (and some commit to print) that iterative delivery makes requirements redundant.
Instead of attempting to do away with requirements, intelligent methods simply approach the requirement needs from a different direction. The real concern – and this applies to any kind of development technique – is to discover what is needed without producing unnecessary, premature, and wasteful reams of documentation.
No matter how you develop software, the need to understand the customer’s business problem, and what that product has to do to solve this problem (in other words, its requirements), remains.
Truth 9
There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.
The requirements activity is not exactly easy; it takes thought and perception on the part of the business analyst if it is to succeed. Several automated tools are available to help with this endeavor, but they must be seen as aids and not as substitutes for good requirements practices. No amount of blindly following a prescribed practice will produce the same result as a skilled business analyst using his most important tools – the brain, the eyes, and the ears.
Truth 10
Requirements, if they are to be Implemented successfully, must be measurable and testable.
At its heart, a functional requirement is something that your product must do to support its owner’s business. A non-functional requirement is the quantification of how well it must carry out its functionality for it to be successful within the owner’s environment.
To build a product that exactly meets these criteria, you must be precise when writing requirements. At the same time, you must take into account the fact that requirements come from humans, and humans are not always, and sometimes never, precise. To achieve the necessary level of precision, you have to somehow measure a requirement. If you can measure the requirement using numbers instead of words, you can make the requirement testable.
It is also safe to say that if you cannot find a measurement for a requirement, then it is not a requirement, but merely an idle thought.
Truth 11
You, the business analyst, will change the way the user thinks about his problem, either now or later.
Once people have a better understanding of the real meaning of their requirements, they are likely to see ways of improving them. Part of your job is to help people, as early as possible, to understand and question their requirements so that they can help you to discover what they really need.
Conclusion
After all that truth, what are requirements really? Simply put, a requirement is something the product must do to support its owner’s business, or a quality it must have to make it acceptable and attractive to the owner. A requirement exists either because the type of product demands certain functions and qualities, or because the owner justifiably asks for that requirement to be part of the delivered product.
So, what did you think? Are we hitting the mark with requirements? Were there past projects that had to be redone because we didn’t solve the real problem the first time? Or perhaps we solved a problem perfectly, but we duplicated efforts because we didn’t realize we already had a way to do solve the problem without extra costs. Whatever your thoughts, I hope this post helped you to see requirements in a new way.