Building software is analogous to building a house: It starts with determining what the customer can afford (budget), wants (requirements) and proceeds to details (specification) and then to construction (design & implementation). After the building is done, it is inspected (quality assurance) and any problems (bugs) are fixed. Finally it is delivered - late and over budget happen here too, for much the same reasons as software projects.
The Project document is like a contract between the architect and the future homeowner. It is basically a management document, dealing with financial and authority issues, and procedures to resolve problems. This document should identify the customer, the financial supporter, the project leader, all of the affected groups and a definition of the customer's goal. Current costs should be identified and the planned cost and schedule laid out, understanding that once the RSD is done, both may have to be revised.
It is easy to cut corners at the start of a project by outlining the Project Document and leaving the hard details until later. It is just those hard details, costs and schedule, that need to be dealt with early on. The reason for this is to bring to light the hidden differences in assumptions between the customer and the project leader. You don't want to be half way into the project when the customer arrives saying "I assumed we would have part one of the system operational this week. Where is it?" Getting schedule and cost down will usually bring out those issues. Resolving them before committing to a project will prevent a lot of grief later, and occasionally prevent a bad project from wasting money and creating problems.
Getting a good estimate for time and cost before the details are decided is very difficult unless the project leader has done a similar job before. Deal with this up front - be sure the customer understands that details do matter and that the schedule/cost estimate is likely to change. One of the main causes of project overruns and failures is the customer 'wish list'. It is all too easy for the customer to add 'nice to have' features during the requirements process, and too easy to agree rather than resist. But each one of these items has a direct cost in implementation and an indirect cost in added complexity and delayed delivery. Get the customer to agree in the project document to make the first delivery a minimalist one. Just the basic functions, no bells and/or whistles. After that, better cost information will prevent marginal items from being added.
The actual Requirements document starts with identifying each major function that the software must perform in concert with the customer. This is where it gets a little tricky. Functions tell whatis to be done, not how to do it or what the screen will look like. Also, telling the difference between when you have a separate function or just a subset of an existing function takes some practice and good communications skills. Building the requirements with the customer should be done by an experienced analyst, not a programmer. The design should not even be considered at this early stage.
Getting the functions clearly defined can be difficult. It will take a few discuss/document/review cycles before reaching clarity, and the result must be reviewed by all the affected groups. This generally results in feedback & changes, but the end result will be complete and accepted by all of the players involved. This is especially important in a large corporate environment. Get any problems on the table first so you can deal with them. Politics may enter in any large effort. That's when you call in the financial supporter and/or customer to deal with political issues. Let them wrestle over who's in charge and final decision making.
Remember Harry Stine's Dictum: "Always use the proper tool. The proper tool for a television repair is a TV repairman".
The Requirements document can be done on a word processor that supports outlining. They can be concisely represented by a structured outline, with notes and comments hidden, or revealed to facilitate detailed examination of a specific point. Rarely more than two levels of structure should be required. If more levels seem to be needed, that is probably because you are getting into specifications too soon.
Be aware of that distinction - it is vital that the functions deal only with what, not how. That is the key to separating the functions, which is a major step to a clean system structure and design. And a clean design is a prerequisite for good object structure, easy revisions and quality software. Good software starts with a clear definition of function.
Suppose your client is the sales department, and their goal is online ordering via the Internet. What functions does that goal require? What assumptions must be made and documented?
To keep this simple, let's assume that all of the web hosting and software will be handled by a professional web hosting company. From the sales point of view, they want:
Unmentioned of course is the desire for this to enhance the sales manager's next raise and promotion. :-}
The list, as it stands, is not a clear set of functions that can be implemented. Let's organize this by customer and sales:
1. Customer
a) Bring to web site
b) Display products to the customer
c) Make purchasing easy
d) Generate repeat visits for repeat business
2. Sales
a) Reduce costs
b) Increase volume
c) Track interest (products looked at)
d) Learn customer demographics, satisfaction and unmet needs
e) Guide to profitable products
Look at 1a and 1d. Both of these are related to the function of drawing the customer to the site. Items 1b and 1c are the purchasing function as seen by the customer. Item 2a clearly relates to the fulfillment function - order processing, payment & shipping. Items 2c and 2d collect marketing information to address volume (2b) by improving traffic (1a and 1d). Finally, 2e affects how 1b and 1c are presented to the customer.
Now we can make a function list:
1. Draw the customer to the site
a) First time
b) Repeat visits
2. Sell products
a) Display products by profitability
b) Make purchasing easy
3. Make fulfillment efficient
4. Collect marketing information
a) Demographics
b) Satisfaction
c) Unmet needs
d) Adjust advertising for 1a and 1b
We're almost done. Note that item 3 is really the back office functions of a sales department and in this case doesn't really fit into the web project side except for collecting the information. It makes more sense to address item 3 as a separate project that improves the whole fulfillment process. It does not fit well in an online ordering project. Finding out this information early on in a project is one of the benefits of building software in an organized fashion.