As Requirements Engineers we all know the importance of requirements that specify what instead of how. We’ve read books about it, we’ve studied the difference. We’ve argued about it on the message board. However, we’ve always done this with respect to the requirements specifications themselves. What about the process we use for getting to good requirements?
Many Requirements Engineers have very different ways of eliciting requirements. Some ask questions a certain way. Some hold meetings a certain way. Some divide and conquer. Some put everyone in the room together and then let them “fight it out”. There are thousands of ways we can get to the root of a requirement – the “what” of the requirement. However, there is a tendency when training requirements expertise to want to explain, step by step, exactly HOW to get to good requirements.
I’d like to ask us all to take a dose of our own medicine. Perhaps we have missed the mark. Perhaps when training someone to write good requirements, we should not attempt to tell them how to gather good requirements but instead we tell them what good requirements look like. We see this in almost any requirements training book. Good requirements are clear, concise, and testable. Then we see lots of examples of bad requirements with lengthy explanations of why they are not clear, why they are not concise, or why they are not testable. The assumption we draw is “there is one correct way to gather requirements to ensure they are good at the end.” This is a bad assumption and the one I want to challenge today.
Rather than examine the process for how we get to good requirements and focus our efforts on tweaking our process, let’s study our results, the requirements themselves, and discuss what about our results we should adjust to make the requirements better. As we get a clearer and clearer picture of what we want the end result to be, we will naturally develop better and better methods for getting there. The most remarkable part is we may all have a different process. From a development team perspective or a business interest perspective, no one really cares HOW we get the requirements documented. Everyone is most concerned with what they say and whether the end product meets the needs of the business.
My advice? Stop trying to figure out how you elicit good requirements. Start looking at the requirements, determining if they are good, and discussing what would make them better. Eventually, as an individual, you may find a particular process that works well for you when trying to elicit requirements. However, your process may vary greatly from your co-workers process. As long as you both end up with good requirements, does it really matter?
