Project Requirements Process R100

R100 - Identify Requirements

DEFINITION

Investigate and catalogue the requirements in a format that is also 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, based upon the “system vision” that has been established (see Process R070).  The requirements will be primarily functional business needs, but may also include technical requirements and commercial requirements where these represent genuine business needs.

Detailed requirements are normally catalogued in Requirements Matrices.  The Requirements Matrix is a checklist of detailed requirements expressed in such a way that the same text could be used:

• to define, agree and document the client organisation’s requirements,
• to state requirements, questions or issues in a format that potential vendors will subsequently be required to respond to unambiguously as part of the selection process,
• to document the requirements ready for the subsequent design, development and implementation of the systems,
• to state business practices in a way which could subsequently be used in user documentation, test scripts, training course preparation etc.

Requirements may be gathered and recorded at differing levels of detail depending on the circumstances.  Typically, these may be:

• Full list of requirements
• List of major requirements
• List of key discriminating factors

PATH PLANNING GUIDANCE

This process is normal practice, but note that the “depth” of information may vary substantially depending upon the circumstances.

DEPENDENCIES

Prerequisites (Finish-Start):

• Project launch

Prerequisites (Finish-Finish):

• System Vision (R070)
• Define topics (R080)

Dependent procedures (Finish-Finish):

• Collate and agree final report (R150)

RECEIVABLES

• System Vision
• Definition of Topics (DoT)

DELIVERABLES

• Requirements Matrices

TOOLS

• Library of Functional Questionnaires for various applications and environments
• 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.
• Example Consultant’s Business Models
• Applicaion Software Configurator
• Application Reference Model
• Business modelling tools, eg IDEF, ARIS

DETAILED DESCRIPTION OF TASKS

Detailed requirements will be investigated, collated, discussed and agreed with appropriate personnel from the client organisation.  The results will be published and agreed formally as an appendix to the Definition of Requirements report (see Process R150).

Level of detail required

The level of detail required may vary substantially depending upon the needs of the client organisation and their attitude to the gathering of requirements.  There may also be differences where the requirements matrix is only being constructed as a tool in the selection process and not as the main list of requirements.  The appropriate style should be defined and agreed with the client organisation.

Typical valid approaches include:

Full list of requirements

The matrix is used as the main documentation of detailed requirements.  This provides a complete catalogue of the organisation’s requirements.

This approach should ensure that the requirements will be fully considered in the selection process and that the vendors should be obliged to make written statements about all relevant capabilities of their products.  The detailed definition of requirements will be of value both for the selection process and during the design and construction of the solution.  It can, however, lead to a large volume of work for the vendors in their responses and for the project team during the evaluation of the tenders.

List of major requirements

The matrix only records the major requirements, without exploring their full detail.  It omits insignificant requirements or requirements which are industry standards.

This approach may reduce the time required to collect and collate the requirements, the time to respond to the Invitation to Tender (ITT) and the time to evaluate the tenders.  It does, however, increase the risk of selecting a solution with a hidden flaw, and the missing detail may still have to be determined during the subsequent design work in the Delivery Segment.

List of key discriminating factors

The matrix contains only requirements which the project team believe will be most likely to discriminate between the potential vendors.  Requirements which any vendor is likely to meet or for which the standard of compliance is of minimal importance are omitted.

This approach is intended to minimise the time and effort required to make the selection decision.  It is of relatively little value in documenting the organisation’s requirements which will need to be fully defined during the subsequent Delivery Segment.

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).

Whichever approach is taken to the level of detail, 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.

Structure of the analysis and findings

The Requirements work and resulting documentation will normally be assigned and conducted following the  list of functional, technical, and environmental topics that has been defined (see Process R080).  This series of headings will be used as the main structure for the detailed requirements documentation.  It may also be used in future processes as the basis to define topics and papers throughout the project.  This breakdown will be used to break the complexity of the overall project into manageable pieces.  Subject to revisions in the overall approach, the list of topics will be used in all further stages of the project, although at times it may be appropriate to divide the topics further when issues are more complex.

In turn, these topics will normally have matched up with the major areas of functionality within the business area.  The high-level business models and/or function and data models used during the “system vision” may be broken down into the specific areas of functionality for the construction of the Requirements Matrices.

Note the importance of good structure in the Requirements Matrices.  The “top-down” view of the business requirements is important in the prioritisation of requirements and in the subsequent assessment, scoring and comparison of vendors’ responses. This is described in detail in Process S060 -  Define and Agree Selection Scoring Scheme.

Fact finding

The basis for most of the detailed investigation of requirements should have been performed in the earlier processes, for example:

• the analysis of existing business processes and systems in the “Foundation” - Process R010
• the understanding of business strategy established in R020,
• the definition of technical, organisational and financial constraints in R040,
• the identification of needs for business change and priorities established in R050,
• the overall “system vision” of the desired new system established in R070.

In this process, the appropriate level of detail needs to be determined and catalogued.  The detail should be confined to the agreed system vision.  It is likely to include further investigation of some of the above topics and investigation of some of the routine detailed requirements for the new system.

A wide range of fact-finding techniques may be required to determine the detailed requirements.  Primarily these may involve:

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

Functional Questionnaires are available which cover questions relating to many application areas.  These may be used as a guide to the appropriate questions to ask in any given area.  The project team member should first review the sample questions to see if they are appropriate to the current situation and make any adjustments as necessary.

In some situations where it is impractical to interview all the right people, it may be possible to send the Functional Questionnaires for completion without meeting the management or staff concerned.

A large library of example Requirements Matrices is also available.  These can be used in a similar way, although care should be taken to ensure that the results from the fact finding are based on the client organisation’s true needs and not simply an acceptance of a large number of standard requirements as expressed in the examples.

General format of Requirements Matrix

A Requirements Matrix is a list of requirements phrased in such a way that it will subsequently be suitable for submission to potential vendors.  At this stage in the project it is prepared as a simple list of requirements needs or issues.  It would normally be in a format such that it can subsequently be reused for several different purposes, in particular initially:

• in this process (R100), as a statement of detailed requirements (ie 1 column table),
• optionally, with a second column showing the “right answers” where these are not immediately apparent from the question, for example “How many currencies can the system handle?” / “Minimum mandatory requirement 4, Desirable requirement 20”.and subsequently:

• to record the “criticality” (Knockout/Business Critical/Desirable) of each of the requirements (ie 2 or 3 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.)

Style of the language used

The requirements, questions or issues 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.  In Application Implementation Projects  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 definition of requirements)
• as an issue or question 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)

Diagrammatic techniques are not normally used at this level of detail as they cannot normally  meet all these objectives.  Diagrams are, nevertheless, very useful in many aspects of the definition of requirements and should be included in other parts of the Definition of Requirements report where ever of value.

The detailed requirements should be suitable for sending to potential vendors.  Confidential information should not be recorded in these documents.  Any confidential items should be included in other sections of the Definition of Requirements.

Application Software Configurator

Where the requirements relate to an Application implementation from a major vendor, the proprietary software Configurator may be used.  This is a vendor specific developed program which makes initial estimates of the total disk space required.  A list of questions and associated estimate assumptions are usuually provided in a spreadsheet format.  These can provide a useful framework for requirements questions.