Defining your requirements

---

If you’re considering investing in custom-developed software for your business, one of the most valuable things you can do is take the time to write a Requirements Document that clearly describes your business and your custom software requirements.

The more information you can supply, the better because it will allow NZCS to make a reasonable estimate of the scope of the project, so we can provide you with an accurate cost estimate.

This page is intended to help you define your requirements. While you don’t have to provide all the information below, the more detail you can provide, the better.

Introduction – about your business

• Who you are
• Where you are located
• What your business does
• Who are your customers, what is your market
• What is the business problem you are trying to solve? (Why you need a new system?)

System Overview – about the software you require

• 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? (e.g. sales and management)
• What level of computer experience will the users have? (e.g. familiarity with Word/Excel)
• What main problems do the users have at present?
• What hardware/environmental constraints are there? (e.g. the system is to be run on Windows 2000 machines each with a minimum of 256Mb RAM.)
• Will it be networked or stand-alone?
• Any other constraints? (e.g. throughput requirements, industry protocols, etc.)
• Approx number of records required initially plus anticipated growth (e.g. 100 customers increasing at 300 per year)
• What Business Rules need to be included? (e.g. the maximum credit limit allowed is 1,000)
• Describe your workflow/business processes
• Do you want to have an ongoing maintenance agreement to keep the software up to date and supported?
• Describe how you currently back up your system.
• Provide any system documentation of your network and contacts that may be helpful to complete the project.
• Deliverables. What are you expecting? (e.g. 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 full source code and 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 NZCS is to maintain the system you may want an escrow agreement (where the source is held by an independent third party). You must state that you need one of these.
• 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?
• What have you been using up to now? Do you require a data conversion?

Functional Requirements

Describe what the system is to accomplish rather than how it is to be accomplished. This should consist of list of features listed in order of priority. Each entry should have the following listed:

• Description of the requirement
• 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 (e.g. only managers should have access)

Data to be Held

• List the tables and fields (e.g. Client, Last Name, First Name, Account Number)
• Auditing requirements
• History: What can be deleted and how long must data be kept

Operational Scenario

Describe a set of scenarios that illustrate, from the user's perspective, what will be experienced when using the system under various situations (e.g. 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 (e.g. nobody available to discuss the project during March, awaiting approval to proceed, etc) and the budget you are working to (you may, or may not, want to reveal this initially but it is a good idea to let the developer know if you want a Rolls, Holden Commodore or a Toyota because software can be designed to a budget).

Appendices – additional information

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.