Project Selection Process S500

S500 - Define Key Requirements

DEFINITION

Investigate and catalogue the key and unusual requirements of the client in a format that is suitable for use in the subsequent selection and design processes of the project.

SUMMARY

Fact finding techniques are used to establish the client organisation’s requirements.  The requirements will be primarily functional business needs, but may also include technical requirements and commercial requirements where these represent genuine business needs.  Fact finding can be prompted by use of standard Requirements Matrices and Functional Questionnaires, but it is important that the client organisation’s key business requirements are identified rather than simply including all the standard questions that are listed.

The requirements are prepared as a series of individual issues, listed in a tabular fashion, for use in the request for information and demonstration requirements.  Vendors will be asked to respond to these requirements and to address each of these requirements during the demonstration of their solution. These requirements will form the basis for evaluating the vendors.

PLANNING GUIDANCE

This process is normal practice in Requirements /Selection Fast Track, but note that the “depth” of information may vary substantially depending upon the circumstances.

DEPENDENCIES

Prerequisites (Finish-Finish):

• (none)

Dependent procedures (Finish-Finish):

• Issue Invitation to Tender - Process S520

RECEIVABLES

• (none)

DELIVERABLES

• Definition of Key Requirements in Requirements Matrix format

TOOLS

• Library of example Requirements Matrices  for a wide range of applications and for differing complexities of environment.  Note that these have been collected from consultant sources around the world and are not all in the same format.
• Library of example Functional Questionnaires.
• Guidelines: Modelling Techniques.

DETAILED DESCRIPTION OF TASKS

The  key requirements will be investigated, collated, discussed and agreed with appropriate personnel from the client organisation.

Level of detail required

The level of detail required will vary depending upon the needs of the client organisation. The objective is to establish the major requirements and document the discriminating factors.

The matrix only records the major and unusual functional requirements.  It omits insignificant requirements which are expected to be standard in all proven software packages.  Furthermore the matrix should include requirements which are likely to discriminate between the potential vendors.  The discrimination could be based upon whether the solution could satisfy the requirement or how the requirement is catered for.

The requirements should be formulated around the key business processes rather than the software modules.  This approach provides the following benefits:

• the client can more easily comprehend the requirements by matching the processes,
• the requirements can form the basis for the demonstration of the solution and facilitate the prototyping processes for the vendors,
• it assists the client organisation in the design and acceptance testing phases of the implementation due to the business process focus.

Type of information required

The requirements will primarily be functional business needs, but may also include technical requirements and commercial requirements where these represent genuine business needs.  For example, it may be a genuine business requirement that:

• orders can be entered by any departmental manager, but need approval by a buyer in the purchasing department (a functional requirement),
• the system operates over the existing network and can be used on the existing PCs (a technical requirement),
• the vendor can demonstrate that they have significant  support capabilities available in this country by quoting their support staff numbers and customer numbers (a commercial requirement).

It will be valuable to identify the major business requirements at this time.  These are essentially of two kinds:

• Business principles - these may be defined at a general level where they are commonly accommodated by the packages on the market.  Example: it might be enough to quote “multi-currency accounting” in the requirements without further details if multi-currency accounting is done in a very standard way within the client organisation.
• Business rules  should be defined at a detailed level where the requirements of the client organisation are very specific.  They should be carefully analysed and documented since they are likely to play a key role in the package selection and subsequent system design.  Examples:
• an inventory valuation method should be described in detail if it is not a normal industry-standard approach such as FIFO,
• if the client wants to control inventories in two independent units (eg quantity and weight), that could be considered as specific and therefore included in the requirements list.

Fact finding

In order to determine the key requirements the following two stages may be appropriate.

1. Document the high-level business processes

Business processes can be documented as text, but it may be more appropriate to use modelling techniques.  An appropriate approach using data flow modelling to document the current processes would be:

1. to establish (normally through interviews with relevant project user representatives) the documents used in the system and their sources and recipients,
2. to document these flows (as “context” and “document flow” diagrams) and with the help of the users to identify the system boundary (ie which flows are within, outside or across the functional boundary of the system),
3. to produce a high-level data flow diagram showing the data stores accessed or updated by the processes within the system boundary, and to walk through this with senior user representatives to validate it,
4. confirm with the senior user representatives whether and how any of the existing processes should be modified in the new system (note that this “Fast Track” approach assumes relatively little business process redesign - a “Full” approach should be taken where substantial redesign is intended).
1. Establish and document the key requirements for the processes identified

A wide range of fact-finding techniques are available to determine the key requirements.  Primarily these may involve:

1. interviewing key management and staff,
2. examining existing documentation, reports, procedures,
3. examining the specifications of existing systems and business processes.

Fact finding can be prompted by use of Consultant’s standard Requirements Matrices and Functional Questionnaires, but it is important that the client organisation’s key business requirements are identified rather than simply including all the standard questions that are listed.

Style of  the language used

The requirements, would normally be expressed as a series of short statements or questions which itemise the detailed requirements into single issues in a format which potential vendors would be able to respond to.  This format will be used for the subsequent “Fast Track” processes.