How to write a Requirements Specification (or how to specify what you want)

	Professional Database Developers
Aldex Software Ltd.

Requirements Specification

Many of our potential clients do not initially supply us with sufficient information upon which to make a reasonable estimate of how big a project is and of how much it is going to cost. In many cases they may not appreciate what information is required. This page is intended to help you supply this information (note that this guide is aimed at non-experts rather than professional business analysts).

The basic document that is needed is called a Requirements Specification. In other words a description of what you want the system to do. This document may also be called a Business Needs Specification. The Requirements Specification should generally NOT be written in computer terms or contain assumptions about how the system should be written (unless these are part of the requirements). The following gives topics that should normally be covered in a Requirements Specification. If you need any help/explanation then please get in touch with us.

Introduction

	Who you are.
	Where you are located.
	What you do.
	Who are your customers/market.
	Your contact details.
	What is the business problem you are trying to solve and why you need a new system.

System Overview

	Who is intended to use it
	How many users are there (both the total number and the maximum number of concurrent users at any one time)?
	Are they the same type of user or different (eg sales and management)
	What level or computer experience will the users have (eg familiarity with Word/Excel).
	What main problems do the users have at present.
	What sort of security (eg different group with different access rights) is required.
	What hardware/environmental constraints are there. Eg The system is to be run on Windows 2000 machines each with a minimum of 128Mb RAM.
	Will it be networked or stand-alone.
	Any other constraints (throughput requirements, industry protocols, etc.)
	Approx. number of records required initially plus anticipated growth eg 1,000 customers increasing at 100 per year; 10,000 jobs increasing at 1,000/year; etc.
	Will remote users need access (eg mobile workers with a laptop). If so do they just need a copy of the database on their laptop or will they need to dial-in to the main system to get the most up-to-date information. Will they be updating information in the field for later downloading onto the main system. Any what about other sites?
	What sort of technical support is available in-house.
	What other systems, if any, will this system integrate/communicate with eg export data to a financial system, import data from Excel, etc.
	What external communications are involved eg automated faxing, import csv data from FTP site, export data to anaccounts system, etc.
	What Business Rules that need to be included, for example maximum credit allowed is 5,000.
	Are there any Business Processes that need to be catered for, eg credit card authorisation
	Are there any technical standards that must be complied with, eg code must be written using the Leszynski/Reddick naming convention.
	Maintainability/future expansion. Include your thoughts on who will maintain the system in future (eg in-house), any plans for future developments, etc.
	Backup. Describe what your current back-up regime is (eg tape back-up one/day) and if/how you expect the new system to fit in with this. If this is not currently defined then think how much data loss you could suffer. For example would it be a major disater if you lost the last 30 minutes of work or would you be happy reverting to yesterday's/last week's version?
	Deliverables. What are you expecting? eg system, help files, documentation, full source code, training, support, etc. Detail what is essential and differentiate these from what would be nice. Don't automatically ask for everything unless you really do need it, for example documentation can be very expensive. If you are to maintain the system make sure you state that you require the full source code - alternatively if the developer is to maintain the system you may settle for an escrow agreement (where the source is held by an independent third party). You must state that you need one of these; if the developer is unwilling then find someone else!
	Reliability. Any reliability constraints? Acceptable downtime? Can you cope if the system is shut down overnight? For an hour during the day? For a whole day?
	History. What have you been using up to now (eg paper, nothing, DOS database). Do you have existing data that needs to be converted to the new system? What format is this data in and can it be exported, eg to a .csv text file.

Functional Requirements
This section should describe what the system is to accomplish rather than how it is to be accomplished. This should consist of a list, with the most important items at the top. Each entry on the list should be specified in a format similar to the following.
	A description of the requirement. This will probably be a couple of lines explaining what you want to achieve. Make sure that you provide sufficient detail. eg Produce a report of spend/department/year on demand with the user selecting the Department and the financial year required (note that you would also need to define how your financial year is calculated!).
	How important is this requirement (essential, preferred, nice to have, not essential, etc).
	Any known design/implementation issues relating to this requirement.
	Does this requirement interact with other requirements.
	Anything else affecting this requirement (eg only authorised personnel should have access)

Data to be Held

Describe what data tables you expect to hold. Eg customer records, contact details, machine records, etc. Provide as much detail as you can. For example a customer record might consist of a name, address, tel. no, fax no, mobile no, region, business type, no employees and so on. Try to indicate any unique fields (such as a job number) and also show how different tables relate to each other (very important). For example Projects are related to Customers through a Customer Number. Each customer can have none, one or many associated Projects. Each Project relates to one or more Jobs. A Job can exist independently of a Project but will still be associated with a Customer. A Project will always have a Customer and cannot have more than one Customer.

It is not usually necessary to define the tables in database terms (eg Customer Number is a long integer) but examples of the data to be held in the fields is useful (eg a typical Job Number might be DT/2345 where DT indicates the department undertaking the job and 2345 is a unique number. NB In practice a good database designer would then recognise that the 'real' job number is actually the 2345 part and the DT bit is just an associated field.). If you know the maximum size of any field (eg Company Name of 100 characters) then include this as well.

If you have any table definitions from existing systems then provide these as well indicating any changes that are required.

Operational Scenario
Describe a set of scenarios that illustrate, from the user's perspective, what will be experienced when using the system the system under various situations. Eg this would describe how different users would use the system and the typical sequence of actions that each would take.

Schedule and Budget
Describe what timescale you are working to, any critical deadlines, any management constraints (eg nobody available to discuss the project during August, awaiting approval to proceed, etc) and the budget you are working to (you may, or may not, want to reveal this initially).

Appendices
Include other information here that may be useful in understanding your requirements. For example definitions of industry specific terms, acronyms, abbreviations, etc. Provide citations to any other documents used in the preparation of this specification.

And Finally....

If you have any comments or suggestions, or if you would like to contribute to this page then please contact us.

Return to front page