Creating the requirements, or What a provider needs to know to deliver what you need?

Target Audience: those who want to have an application developed, not having enough experience in elaborating the requirements specification.

The world is full of bright people who strive to make our lives better and easier by introducing new great services and products. If you're the one inspired by some great idea and looking for ways to bring it to life, you might have already noticed that to make something real you need to have a very clear vision of it, especially when you're planning to hire a team to implement your idea. Now here comes the moment of creating the requirements for the prospective application. You have to understand that making the requirements document is one of the most important stages of project implementation. If the document fails to represent all the system’s details it may lead to dire consequences. A decent developer never starts working until provided with satisfactory requirements, and this need is fully reasonable, not just a caprice. Moreover, creating the requirements gives you a better notion of the desired result.

The requirements document should contain all the information the developer needs. It should not necessarily comply with all the RUP (Rational Unified Process) rules – this would take much time and most of the projects do not require such documentation. But it would be surely helpful to split the document into chapters and add the table of contents: requirements usually make at least several dozens of pages. Also, the more detailed the description is the easier you will make the developer deliver exactly what you need.

So, where do we start? It would be best to begin with certain introduction – acquaintance with the subject area, which means high-level description of the application: target audience and its involvement in the project, key use cases, benefit of the application’s owner etc. All the above helps the developer understand the idea. Thus it will be easier for them to get into the details and point out the key aspects. It would be good to mention similar applications on the market, if any.

After you have identified the project goals you can proceed with specific details. You should begin with defining all the application’s user roles (or actors in the RUP vocabulary) with brief descriptions.
For example:
- Anonymous User – a user who can view goods descriptions on the site.
- Buyer – a user who can buy the goods on the site. Can do everything an Anonymous User can do.
- Seller – a user who can sell his/her goods on the site. Can do everything an Anonymous User can do.
- Administrator – a super-user who can change any system settings, edit any goods and other users and view reports. Can do everything users with other roles can do.

Now you should list all the possible options of using the application (use cases). Each use case description must include: user roles for which the use case is available; initial state of the system; step-by-step user’s actions and the system's response to these actions. It’s preferable to present this information in use case diagrams, but if the case is simple a text description will be enough. Use case description is one of the most important things required by the developer to implement your project because it explains the application’s functionality.
Here is an example of a “Buyer Registration” use case description:
Roles: Anonymous User.
Actions:
1) User opens the main site page.
2) User clicks on the “Register as a Buyer” link.
3) User is shown the buyer registration page.
4) User enters the information into the form fields and presses the “Done” button.
5) If the required fields of the form are not filled, then: display the “Fill the required fields” message, go to step 4).
6) User becomes a Buyer and is redirected to the main site page.

After all the functionality is described you need to show the way it should look on the screen, i.e. user interface. If there is no graphic design yet, it is a common practice to use layouts, i.e. schematic description of the GUI. Requirements presented as graphics are often much easier to understand than plain text, so please do your best while working on this section.
It would be reasonable to start describing the GUI with the list of screens or pages (if the subject is a web site). Such a list shows the developer the size of the graphic interface and also can be used as a brief guide.
Many text editors, such as Microsoft Word and Google Documents, allow adding hyperlinks to different parts of the document. It would be useful to link each screen to the corresponding description. This function is worth using in all the document’s parts to link different sections, making navigation easier.
It’s better to create the layouts with help of special applications or services which allow saving layouts – you may find this useful if you need to make corrections. An example of such a service is http://gomockingbird.com. Just like with the text description, detailed layouts let the developer fully and properly understand the task.

Last but not least, you must note if there are any non-functional requirements for the system to develop, for example: user interface response time, number of users at a time, devices the application should work on, and so on. This information is all-important for development because it may save a lot of resources on system modification on later stages.

Expressing your ideas in text form is a sophisticated task which requires certain skills. But the most important thing in creating the requirements is your will to make the developer understand everything correctly. The less uncertainties in your document, the more likely you will get exactly what you expect.
Remember: you know best what you want, but passing this knowledge takes a lot of time & effort.