Information Technology System Requirements

Description

• 
  The investigation and documentation of the Information Technology (IT) requirements of redesigned processes that drive either the selection of a “package software solution” or the development of a “custom software solution”.
• The requirements are primarily “functional” business needs, but may also include technical commercial requirements, where these represent genuine business imperatives

Business Value

• Identifying and documenting business requirements for newly designed processes is critical to ensure that the IT solution will be adequately support these processes
• If the business requirements of an organisation are not documented and understood, the possibility of a purchase of a software solution that does not support the business without an excessive amount of modifications is significantly increased

Approach

Prior to identifying IT requirements, decide upon the level of detail at which requirements are to be documented (based on information needed to accurately describe the business as well as other factors such as the resources and time available to complete the effort). Prioritize identified requirements, for later use as “weighting factors” in the selection of software vendors.

1. Determine level of detail of the “functional” IT requirements (and any “business” requirements)
1. Full list of requirements—Ensures that the requirements will be fully considered in the selection process.  Request that vendors provide detailed documentation on the capabilities of their products.  A detailed definition of requirements is of value both for the selection process and as well as for the design and construction of the solution.
2. List of major requirements—Major requirements are identified without exploring their full detail.  This deliverable omits insignificant requirements or requirements which are considered industry standards.
3. While this approach may reduce the time required to collect and collate the requirements, it does, however, increase the risk of selecting a solution with a hidden flaw that will surface during the later implementation activities.
4. List of key discriminating factors—Document only those requirements which the project team believes are most likely to distinguish between potential vendors.  Omit those standards that most vendors are likely to attain or for which the standard of compliance is of minimal importance.
2. Identify the “functional” IT and “business requirements” of the redesigned processes.
1. These requirements will refer primarily to the functional capabilities essential to meet business needs, but may also include other requirements that represent business rules that need to be adhered to or vendor capabilities that must exist, such as:
1. Orders that can be entered by any manager, but require approval of a
2. buyer in the purchasing department
3. Vendor can provide 24 hour/day, 7 day/week support services if needed  (e.g. by providing their support-desk and numbers and locations)
3. Prioritise requirements and perform weighting (if necessary)
1. Differentiate between those requirements that are absolutely vital (and without which any proposed solution would be unacceptable) and those requirements that are not nearly as critical.
2. One recommended approach is to use a three-tier system of priorities
1. Knockouts
1. Requirements which are absolutely vital to any proposed solution.  If a “knockout” requirement cannot be met then that solution should be rejected immediately.
2. Business Critical
1. Requirements which are critical to the operation of the business.  If they cannot be met it would result in significant difficulties.  Failure to meet a business-critical requirement seriously reduces the attractiveness of the solution, but does not rule it out.
3. Desirable
1. Requirements which are genuinely of value to the organisation, but which would not present any major operational difficulties if they could not be met.
3. In some cases, the prioritised requirements are also weighted so that their relative importance is reflected in the scoring and evaluation of vendors’ responses during the selection process.

Guidelines

Problems/Solutions

• In some cases, design team members will want to go into excessive levels of detail in order to be sure that requirements are not “missed” during the selection process. Make sure the requirement identification effort remains at the predetermined level of detail.

Tactics/Helpful Hints

• Once agreed to, the weighting scheme should not be revised unless a compelling reason is found.  It should not be routine practice to revise the importance of a requirement based on the proposals received as this encourages the manipulation of the questions to get the “right” answer.

Resources/Timing

• Make sure the appropriate decision-makers are involved in the design of weighting  schemes.  High-level weighting can decisions can be made by management , however detailed weighting measures are best left to staff who have a complete understanding of the detailed tasks and requirements.
• During a vendor selection exercise, state requirements/questions in a clear format to which potential vendors will subsequently be required to respond unambiguously.
• Present business practices in a way that they are readily-transferable for subsequent usage in employee documentation, test scripts, training course preparation, etc.