Project Selection Process S045

S045 - Format Requirements Matrix (Hardware Selection)

DEFINITION

Identify and document the client organisation’s requirements for hardware into a Requirements Matrix format, suitable for inclusion in an Invitation to Tender (ITT).

SUMMARY

The requirements are prepared as a series of individual issues, listed in a tabular fashion for use as an early section in the Invitation to Tender.  Vendors will be asked subsequently to respond to these issues, and should normally write a detailed response to each of the specified issues.  The tenders will be evaluated against these issues.

The requirements will typically have been established by some earlier process in the Application Implementaton Process  path.  For example, it may already have been decided to use a certain application package, in which case the ability of hardware to support that application at the right scale and performance levels will be a key part of the requirement.

PATH PLANNING GUIDANCE

This process is normal practice in hardware selections.  It is required because suitable documentation to support an ITT for hardware selection would typically not have been generated prior to this point.

DEPENDENCIES

Prerequisites (Finish-Finish):

• R150 - Definition of Requirements (either per Requirements Segment or other method)

Dependent procedures (Finish-Finish):

• S080 - Issue Invitation to Tender

RECEIVABLES

• Definition of Requirements (or client organisation’s equivalent documentation)

DELIVERABLES

• Requirements Matrix (not yet prioritised)

TOOLS

• Requirements: example Hardware Requirements Matrix.

DETAILED DESCRIPTION OF TASKS

General format of Requirements Matrix

A Requirements Matrix is a list of requirements phrased in such a way that it is suitable for submission to potential vendors.  Initially it is prepared as a simple list of requirements needs or issues.  It would normally be in a format such that it can be re-used for several different purposes, in particular:

• as a statement of detailed requirements (ie 1 column table),
• to record the “criticality” (Knockout/Business Critical/Desirable) of each of the requirements (ie 2 column table)
• as a series of questions to pose to the vendors, showing whether or not they are mandatory and usually with space for their responses alongside the questions (ie 3 column table),
• to record the detailed prioritisation and weightings determined by the project team and client organisation for the evaluation of responses (normally a 3 column table showing both criticality and weights per issue, coupled with summary tables to record weightings for each sub-section and section in the overall table),
• optionally, as a table of all vendors’ responses alongside the original questions (ie multi-column text table),
• as an evaluation table showing the project team’s assessment of the responses alongside the questions in a tabular form (ie multi-column text and numeric table).

This reformatting can be achieved using many spreadsheet tools or word processors.  It would be normal to use the client organisation’s standard tools provided that they can manipulate text and numeric data in tables as required.  Provided there is sufficient time to prepare, it may be possible to supply the requirements to the vendors in this electronic format requesting an electronic copy of their responses as well as a formal printed and signed copy.  (Some projects have attempted a quantised self-assessment form of response allowing automatic calculation of comparative scores, but this is not yet normal practice.)

Scope and level of detail

The scope of the requirements should cover all requirements in sufficient detail for a supplier of IT hardware to propose a complete solution to the requirements.

A number of important considerations arise for hardware selection that may not have been researched in detail by earlier Software Application Implementation processes.  Such considerations should be researched at this stage and documented in the Requirements Matrix.  Depending on the exact nature of the engagement, these issues include:

• details of any specific application packages that the hardware is required to support;
• details of any specific RDBMS or TP monitor that the hardware is required to support;
• numbers and locations of users;
• performance requirements, such as user transaction response within 2 seconds, overnight batch to be completed within 7 hour window;
• anticipated transaction rates (peak and average);
• interfaces to other systems, whether hardware or software, new or legacy;
• infrastructure requirements, such as network limitations and protocols, either to be provided as part of the ITT or as a given with which the response must conform;
• security requirements;
• serviceability requirements, such as “nine-to-five”,  “24 hours a day, 365 days/year”;
• resilience to failure, such as continuity in spite of disk error;
• system and network management requirements, either for provision of the new system or for the ability to work with client’s existing solutions (e.g. must support SNMP or CMIP protocols);
• compliance with Open System standards, such as XPG4, POSIX, ANSI C and ANSI SQL.

Approach

The requirements should be reviewed and converted into 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.  In Software Application Implementation processes we try to re-use text as much as possible to minimise the work required.  Accordingly, the text would ideally be written in language such that it is suitable:

• as a statement of the requirement (to form part of the statement of requirements)
• as an issue for response from the vendors (to be included in the Invitation to Tender document)
• as an element of the design of the system (to be included in the relevant Implementation Paper and for the definition of system tests)
• as a statement of how things are to be done (to be included in the user documentation and training materials)

In addition to the items which represent true requirements, a Requirements Matrix should normally include other questions for information only.  These are intended to collect important information from the vendor, for example, which version of the software their responses refer to.

The Requirements Matrix should be structured into a format which makes it easy to follow and subsequently easy to evaluate.  Typical main sections might include:

• establish the precise products, version numbers, availability details, external requirements and assumptions etc  that the vendor is referring to in the tender document,
• questions/requirements about the vendor and the standard of service, support, training etc (requesting pricing information where appropriate),
• integration and interfacing,
• security,
• other functional/business requirements,
• architecture, eg client server, type of database, type of TP monitor, etc,
• communications network requirements, eg types of server, WANs, LANs, protocols, remote printers, PCs or VDU’s etc,
• hardware and system software requirements,
• backup, restore, recovery and archiving requirements,
• volume handling requirements - processor power, disk space etc,
• other technical environment requirements,
• costs, fees, recurring charges, licences, user limits, processor size limits etc - this detail can be included in Requirements Matrix or it can alternatively form a separate part of the Invitation to Tender document.

At this stage, no prioritisation need be performed on the issues.  Priorities (criticality and weights) are determined in later processes (see S070 and S090).  If the Requirements Matrices are being created in a single session with empowered representatives of the client organisation, it may be possible and efficient to perform the prioritisation at the same time.