System Selection - Platt & Hill Limited
Platt & Hill Limited, an independent company, specialising in the manufacture of products primarily for the furniture trade, commissioned us to select a replacement for their existing ERP system.More Info

IT Strategy & Systems Selection - Ferranti Technologies Limited
Ferranti Technologies Limited, a world-class supplier of electronic, electrical and electro-mechanical equipment, commissioned us to undertake an IT Strategy Study, followed by a Systems Selection.More Info

IT Strategy - a Stately Home
This 18th Century stately home is now run by a Trust. We were commissioned to produce an IT Strategy to enable evolution from a series of separate systems to an integrated suite of systems.More Info

Selection of Software Developer - Dyson Insulations Limited
Dyson Insulations Limited, which specialises in cavity wall and roof insulation, and home heating systems, commissioned us to select a software developer to develop new applications systems.More Info

Statement of Requirements

This is the fourth page of the sub-web on Selecting ERP, and other Application, Computer Systems

The task is to produce a Statement of Requirements, which defines the company's needs in normal English, not in either computing or industry jargon. The purpose is threefold:

  • to enable potential suppliers to obtain a clear idea of what is needed and provide sensible quotations;
  • to provide a checklist to measure how close potential suppliers come to the company's needs;
  • as a weapon to hit the supplier with if the system, subsequently, does not perform properly.

Accordingly, the Statement of Requirements should contain:

- An introduction explaining:

* who is seeking the system,

* who for,

* what the broad objectives of acquiring the system are,

* what timescale constraints apply,

* what cost constraints apply;

- any other general relevant comments e.g., if the computer will have to work in a dirty, hot, or cold environment, or if long cable runs will be required;

- a description of each of the individual tasks which the system will have to perform. Each task should be individually described and should be sufficiently clear and unambiguous so that an average person, with no technical knowledge of computing or the company's business, could understand it and explain it back to you.

It is better to break this section up into points or small paragraphs rather than to have long blocks of text. It also helps a supplier to identify points for clarification more easily.

- A description of the information to be input (optional).

If existing or new forms are to be used, a copy, with typical information already filled in, is useful. If there are peculiarities in the data then these should be identified. Typical points include:

* variable occurrence information, where you can have any number of entries, for instance the dates and outcomes of meetings;

* conditioned information, where a certain value in a particular field can result in information either being or not being present, e.g. the question 'has the part moved in the last six months' could result in an 'N', and no details, or a 'Y', and a variable number of occurrences of dates, and descriptions;

* relationships between fields, e.g. an 'M' in the sex field will mean that only codes 'A', 'B' and 'C' can be used in another field, whereas an 'F' means that codes '1','2','3' or '4' could be used.

- A description of the outputs (optional). The layout of any printed or screen reports, that are known to be required, would be useful. This does not mean that you need to devise new layouts if one has not been drawn up but a list of the information, which you require would be useful. Quite often, broad requirements only need be indicated. As examples, it should not be necessary to indicate the information required on documents as diverse as cheques, aged debt reports, or stock valuation lists;

- information on procedures, techniques, constraints et cetera, which are peculiar to the industry or company, but are unlikely to be known outside the company. These can be simple, such as industry settlement dates, or the weight increase in raw steel due to oxidation, to complicated matters such as computing the figures required by the Stock Exchange to control exposure by market-makers.

The usual procedure, which we adopt, is as follows:

- after the first round of interviews have been conducted, we produce a summary paper listing the major features which we believe that the systems will need to provide;

- this document is circulated to all interviewees for their comments;

- during subsequent interviews, usually planned to cover difficult areas, we talk further with those people who have raised corrections to, or comments arising from, our summary document;

- we then write the Statement of Requirements;

- we now seek the opinion of the interviewees to the Statement of Requirements. For some clients, rather than circulate a large document to many people, we send each interviewee a copy of those sections, which affect them. The senior managers and directors get a full copy;

- in the light of any corrections from the interviewees, we hold discussions with senior management and agree any revisions;

- a section, covering information which potential suppliers should provide, such as level of engineering support, warranties provided, et cetera, is added, and the document is changed into an Invitation to Tender ('ITT'), ready for issuing to potential suppliers.

Examples drawn from various Statements of Requirements are available in the downloadable guide, available as Download Systems Selection Guide, but are not included in this part, because of the number of pages involved.

If the document is being produced in-house, it is probably sensible to get it reviewed, when complete, by somebody who has significant experience in computer selection, as this is the document which suppliers will tender against and which should be cited, in the final contract, as an unambiguous statement of the user's needs.