Before one can begin building an application one has to know what it is that the application needs to do. This sounds like a simple idea, but it’s really not. Take a look at my old entry on why software projects fail and you will see that the first reason listed is "Project Requirements are Poorly Defined".
Many failed projects start out with great intentions. Perhaps a developer, manager, business analyst or executive comes up with a brilliant idea. Immediately, a developer, or a whole team of developers, is called into an emergency meeting and a brain storm session ensues. In this session ideas fly widely! Proposals are proposed! Considerations are considered! Ideas are thought out, planned, sliced, diced and dissected. A new application, website, component or whatnot is conceived. Then, when the orgy is completed, everyone stumbles out of the conference room, feeling a little dazed, strung out and worse for wear.
But the ideas! Oh, the ideas!
Three weeks later the team is reassembled for a demonstration of the new application, website, component or whatnot. But, the afterglow is gone. The orgy of ideas has turned into a nettlesome collection of preconceived notions. The product which is demonstrated does not do what anyone expected it to! How can that be? Everyone agreed on what the project would be, didn’t they? Well, let’s check the requirements document…
Wait a second; we don’t have a requirements document!
Oh yes we do! The developers took notes!
Notes?! Did someone sign off on the notes?
It turns out that, no, no one signed off on the notes. And even if they did, the notes were composed entirely of these words:
Build a new application, website, component or whatnot with a bunch of wiz-bang features.
Has this ever happened to you? I expect so. The question then beckons, what can you do about this?
The answer lies in requirements gathering. I have a simple forms application I wrote which I work though when gathering requirements. The form focuses on the following items:
- The business process which will be modeled by the application
- The user and systems which will use and interact the new application
- The resources which the system depends on and creates
- The functionality of the system as related to the first three items.
At some unspecified point in the future I will release this application for free. I can’t do that at the moment. As a substitute I will provide the questions on this form.
Before we get to that point, consider that a requirements document is fluid and should feed the design and architecture phase of development. I prefer an iterative technique where each iteration builds on top of work completed in previous iterations. On each iteration you should revisit the requirements document. You will want to adjust it to incorporate new requirements and update it for the next iteration’s requirements.
You may also want to consider keeping versioned numbers of the document. The version number might correspond to the latest change requirements. You can also refer your clients to specific versions of the document when they have questions. Lastly, your clients should sign off on the requirements for each version of the document.
The requirements document also feeds right into the first phases of architecture. The first steps into a UML diagramming tend to be though Use Case and Class diagrams. Your requirements document will help you better identify your use cases and actors which lead into modeling classes and then into other portions of UML.
Without further ado, here are the questions I use when creating my requirements documents:
Identify major portions of the business process. For each, answer the following questions.
Identify the system users and roles. These may be people, systems, devices, etc. These are classifications of people and not individuals. For each user or role answer the following questions.
Identify resources, information, or data which the system will rely on. Refer to the resources section under system users for examples to draw from. For each resource answer the following questions.
Identify the functional portions of the system. Review the user section for inspiration. For each piece of functionality answer the following questions.
To clarify the difference between constraints and rules, think of constraints as unchangeable while rules are agreed upon ways of working. For example a tightrope walker can agree to use a net but can not change the law of gravity. The law of gravity is an unchangeable constraint. The use of a net is an agreed upon way of working and is changeable.
I have an example requirements document I wrote for the ongoing UML entries I’ve been adding. The requirements document is for a Search System API based around the Lucene search engine. The document can be downloaded in the attachments section below. Because this is merely for internal development I have not added a version number or a signoff.
I will be following this entry with another entry on UML use case diagrams.
What’s your strategy for requirements gathering?