Building a Requirements Document

Sections of this topic

    What is going to happen after all meetings have been completed for a project proposal? How will it all be documented? One of the most important documents that a Technical Writer will create at the onset of a project is the Requirements document. It is basically an agreement which ensures that the client and the project managers are all on the same page. As a whole, it describes the project and outlines the client’s requirements and expectations. After participating in a wide range of meetings with all parties, and all essential information has been gathered, the Technical Writer will categorize the information and create a Requirements document. A Requirements document should contain:

    • Date and authorization –lists dates, attendees, and decision makers.
    • Description of the document – indicates the scope of the project. Include a brief description or explanation of the project, e.g., a new application or reporting process is being created, a pre-existing web site needs updating, or a customized version of an old application is needed. Make sure you include the client’s requirements and expectations. After this, note any additional partners or users that will be involved.
    • Overview –describes the purpose and reason behind this project. Explain the circumstances that led to this new project. Provide a sentence or two on the business goals, funding, technology, or the intended audience of the new product.
    • Proposal –indicates how the task will be accomplished. Include items, i.e., a migration will be involved, purchasing new equipment, or hiring consultants. Most importantly, specify time and expenses.
    • Reason –validates the proposal. Note the benefits or advantages of this new product, application, or process. Why is this necessary? List all the pros and if any, the cons. If the case calls for it, outline previous features vs new beneficial features.
    • Specifications –details the core requirements, e.g., equipment involved, database access, what has to be done-new tables, files, system enhancements, software needed, documentation, testing, etc. Include dates for priorities, milestones, and deadlines.
    • Resources –indicates who will be involved- Developers, DBAs, Testers, Lead Project Manager, Sub-Contractors, etc. This will ensure you have the right amount of personnel to perform the job as well as the right people; else training will be required.
    • Security –lists the types of maintenance and issues discussed and planned out, such as protocols, archives, contingency plans, etc.
    • Diagrams and process flows –visually clarifies and reinforces the project and its systems or processes. Depending on the project, include an image of the completed product.
    • Marketing –indicates when marketing comes into the picture and describes their marketing approach. Note any training or documentation (user’s guide, training manuals, advertising material) needed.
    • Distribution –indicates what form of delivery is needed, e.g., what form of shipping is needed.

    Outline and use sub-headings for each of the bullets above for further explanation. Once the document is completed, send it to the client and respective project managers for verification and approval. If the document is of considerable length, indicate what sections should be read by which party. Once all parties sign off and agree to the content, the Technical Writer can then begin to create the Technical Specifications of the product for the System Engineers, Developers, Manufacturers, etc.

    The Technical Specifications document will be described in the next post. If you have any questions, or feel I’ve left out information or wish more information on an item, please leave a comment.