As in govern, determine; requirements statements rule.

Some people think that you have to choose between requirements statements and use cases. My experience says otherwise.

A requirement is a criterion by which something must conform in order to satisfy what is required. Simple enough. And a requirement statement is a form of expressing the requirement. As you might expect, it is just the stating of the requirement in a simple sentence format. The more it fits into a bullet point format, the better.

Contrary to a popular myth that focusing on requirements statements is at odds with using use cases and performing an agile or other type of aggressive development methodology, starting off with requirements statements actually enhances whatever type of methodology you plan to use. That is because they are the foundation for what will be put into the use cases, application visuals, prototypes, and what-have-you. Requirements statements represent what is in the business owner’s mind.

Time and again I have seen an organization (large, famous, global ones) dive right into use cases, experience all sorts of confusion and turmoil on what should be in them and how they should be formatted. I have seen them waste millions and millions of dollars by launching directly into prototyped development. And then in the end (actually the middle which should have been the end), they go back to the basics which is requirements statements.

Like everything else in project development documentation, requirements are to some extent “living”. There should be some sort of approval and change management process. Requiring sign off of requirements statements gets the business owners involved and committed versus letting them be passive and distanced from the project. It is important to understand that gathering requirements statements need not take 6 months as comes to mind for the traditional waterfall development process. In fact, they can be initially drafted in a very short time such as a week or a day. And their approval and changes can be managed via email versus formal review. (Nevertheless, they are real, tangible, and written down!).

With requirements statements in place, working on the to-be process flows and use cases makes sense. They have context and meaning.

For one of my ecommerce clients, Sterling Commerce, I took things back to basics for them and began with requirements statements. Very quickly we were into process flows and use cases. So, how did it turn out? Well, let me answer it this way… The project completed on budget and the product launched on time, and later my client manager told me, “Our development lead loved you – you are the best BA we have ever had!”

Starting with requirements statements does not mean sacrificing your use cases; it means making them better.