Mastering the Requirements Process by Suzanne and James Robertson
With more than 500 pages, this book about the requirements process by Suzanne and James Robertson provides a lot of valuable material about on this crucial activity of software development projects. “Garbage in, garbage out” was what I used to hear at the beginning of my software development career and it is still true today.
You will find this book useful whether you are working in a “just enough requirements” environment or if you have more stringent requirements about what your requirement should contain.
Mastering the Requirements Process. Source: http://www.volere.co.uk/masteringrequirementsprocess.htm
Read my complete review of Mastering the Requirements Process on http://www.softwaredevelopmentbooks.com/requirements/mastering-the-requirements-process/
Reference: “Mastering the Requirements Process” (3rd edition), Suzanne Robertson and James Robertson, Addison-Wesley, 522 pages, IBSN 978-0-321-81574-3
When you are trawling for knowledge, much of what you hear is a stakeholder’s idea for a solution, not a description of the underlying problem to be solved. This could be a terrific solution, but more likely it is a solution limited by the stakeholder’s experience and imagination. Moreover, as yet you (and your stakeholder) have no idea whether it is solving the right problem.
So your task as the requirements discoverer is to interpret what your stakeholder is saying and uncover its essence.
How the work physically accomplishes its functionality – the technology, the instruments, the computers, the people, and so on – is its implementation. To get to its essence, you must ignore any current or future implementation, and reveal the fundamental reason that the work exists. There are several reasons for doing so: The first, and most important, reason is that you solve the right problem – this is obvious but often overlooked. The second reason is that finding the essence means that you don’t inadvertently reimplement outmoded technology. Technology and the organizational structure that were appropriate several years ago when the current system was built will not necessarily be the relevant solution today. And if that is not enough, getting to the essence means that you can avoid the proposed flavor-of-the-month solution that your stakeholder is fixating on.
The problem, meaning the real business problem you are trying to solve, exists regardless of any technological implementation. This underling business problem – perhaps you prefer to call this the policy – is the essence.
You can reverse engineer the essence from a technological implementation. For example, think of an automated teller machine: What is the essential piece of business that you conduct with an ATM? The actions that you have to take -such as insert a plastic card, enter a PIN, have your retina scanned, and so on – involve interacting with the technology the bank chooses to use. The essence, however, is that you safely access your bank account and withdraw money from it.