IT Requirements definition

What is IT requirements management?

IT requirements management is the translation of business requirements to an operational IT system. Where system development is required, your role as the customer is:

• to ensure that your requirements have been correctly specified in consultation with users
• to ensure that providers understand what you want
• to monitor progress and any changes in requirements
• to ensure that users (or their representatives) are involved in prototyping and development of the user interface
• to check that the delivered system meets business need.

This briefing explains your customer role and outlines the development process from a customer perspective.

Why is it important?

Whether your IT requirements are to be developed in-house or outsourced, all the activities up to the production of a specification of business requirements are your responsibility as the customer. Many information systems development contracts assume it is possible to know what the requirements are at the start, and that is possible to produce a specification that unambiguously expresses the requirements. For all but the simplest systems this is rarely true. Requirements analysis is an iterative process; the system requirements will change during the period the system is being developed. It will require user involvement throughout the development process. You will also need to be aware of the implications for fixed-price contracts and change control.

System development is complex and subject to rapid change. You must consider the advantages of modular or incremental development, perhaps with more than one provider; you will be responsible for deciding on an appropriate customer/provider interface.

You must also be aware of the implications of the cost of maintenance when the system is in operation. Requirements will change during the life of the system and maintenance costs can be a major component of the total cost of ownership.

Key factors for success

Key factors for success are:

• close consultation and involvement with users to ensure that their needs really will be met and that the new system will support the proposed processes
• willingness on both the customer and provider side to work collaboratively
• scrutiny of provider plans throughout the procurement process; this is essential in ensuring that objectives are delivered.

You must pay particular attention to ergonomics and human factors; if users do not like the system they will not use it. Usability criteria should be incorporated into requirements and design documentation. You must also consider special user needs, such as disabled users, circumstances of use, novice/expert users.

Who is involved?

Roles involved in IT requirements management include:

• managers within the customer organisation responsible for defining the contract roles and deliverables
• end-users of the system (or their representatives, where appropriate - eg representing the citizen)
• customer/provider analysts involved in a joint requirements capture exercise
• customer/provider managers concerned with:
  - managing the contractual relationship
  - provision of requirements
  - quality control
  - audit
  - testing against business needs.

The Senior Responsible Owner is ultimately responsible for definition of IT requirements.

Business analysts are responsible for identifying and documenting the functional and non-functional requirements for meeting business need. They should have a good understanding of the business area and be able to identify opportunities for effective use of IT.

An acceptance team is responsible (as members or representatives of the user community) for specifying and documenting acceptance test specifications, and for carrying out acceptance tests to ensure that all the specified requirements have been met.

Information systems will not work if end users cannot or will not use them. End users include users within user organisations in public sector, and external users such as the general public - all of these groups must be taken into account.

The requirements of end users must be taken into account in information system design. As they will ultimately be most closely involved with new systems, end users have a useful contribution to make to IS development. They should also be involved in system testing and acceptance (customer satisfaction from the user viewpoint).

Principles

You should aim to select standard packaged solutions wherever possible to meet your requirements. If a purpose-built system is the only viable option, ensure that it will meet a real business need.

Users have formally defined roles and activities as user representatives in strategy development, requirements definition, systems testing and acceptance. They should be actively involved in identifying the requirements for:

• user interface design
• user training procedures and facilities
• support activities, Help Desk procedures
• User Groups, feedback mechanisms.

Effective requirements management ensures that the delivered system meets the customers' expectation on content and costs by maintaining a common understanding of the requirement at each stage of the project, securing a requirements baseline and controlling changes to it, and making the baseline visible to all stakeholders.

You must also take account of requirements for interoperability - that is, the means of ensuring that your systems will be compatible with others across government (see the e-government framework for interoperability). In addition, you will probably have to consider compatibility with existing 'legacy' systems in your organisation (see Infrastructure Management).

Processes

You should take an incremental approach to system development, in which the risks are controlled through manageable stages of building up the required functionality.

A typical development process involves, for each increment:

• requirements planning
• approval of proposed increment
• production of increment
• review of increment; this includes development, testing and release of each increment.

Before commissioning systems development, you should have carried out business analysis as part of strategic thinking about the IS/IT support that your business needs (see Business transformation),

When deciding on the support you need for requirements analysis, consider these questions:

• as the customer organisation, should we just specify the desired outcome, or be significantly involved in the process used to produce the outcome?
• which requirements analysis approach is appropriate to the system under consideration?
• how is the developing information system to be validated against the business requirements (which will probably change)?
• what verification techniques to prevent requirements specification errors are to be required of the provider?
• how is the software to be accepted as meeting the business need (as distinct from conforming to a formal specification?
• The notes below provide a range of solutions to those questions, depending on your individual circumstances.

A generic view of the process

There are a number of different approaches to system development; criteria for selecting an approach depend on critical factors such as time constraints, complexity of requirement and/or uncertainty, with consequent likelihood of the need for an incremental approach. With each approach there will be a series of iterative steps in which the requirements specification is translated from information system requirements into IT requirements, tested for its fitness for purpose and usability and ultimately implemented as an operational system. There may be prototypes and/or pilots; development could be in incremental stages or in discrete components as modules.

A simplified view of the process is shown in Figure 10. It represents a generic framework for development for bespoke information systems and underlies many of the software engineering methods that your provider will be using. The boundary between customer and provider activities will vary depending on your contractual relationship.

The start point, at the top left of the figure, is an initial general and incomplete statement of business activities to be supported by an information system; this is successively refined to form a detailed and complete specification. Development proceeds down the V in a number of phases, each phase delivering a more detailed and precise expression of requirements. The lowest level is capable of being translated into code that the computer system can understand and execute.

The right hand side of the V represents the phases of testing the developed system against the different levels of specification, working from the lowest level back to the top. The final step is for the complete system to be tested against the problem statement to ensure that it meets the business requirements.  

Figure 10: A framework for system development

Requirements specification

You will need to document your business requirements in a form that:

• gives the necessary level of detail for the provider to deliver the specified product or service
• gives the user enough detail to support the acceptance of the delivered product or service.
• Requirements can be categorised as:
• functional - stating what the product or service should provide (such as process applications for licences)
• nonfunctional - quantifiable statements specifying how a functional requirement is to be provided, how well or to what level.

You should specify whether requirements are mandatory (essential features that must be provided) or desirable (options that would add value but not essential for inclusion in providers' proposals). Your requirements must be described in quantifiable or measurable terms so that you can check that you have got what you asked for. A statement of requirements should be unambiguous in setting out:

• what the requirement is (both functional and nonfunctional aspects)
• who requires it
• when they require it
• why it is needed and how important the requirement is to the business.

You should specify service level requirements (such as service hours, availability), any security restrictions, business continuity issues and usability requirements.

Acceptance testing

This is the stage of system development that consists of a series of tests designed to demonstrate to the user that all the specified requirements have been satisfied. The purpose of end-user acceptance testing is to confirm that the system is ready for operational use.

In practice, requirements specification may evolve during the process of system development. Some requirements in the original specification may not have been implemented because of cost or time constraints, or because a more efficient solution has been achieved. Refinements to the requirements may have been identified that do not fundamentally alter the scope of the system.

Acceptance tests usually investigate correct function in handling data, resilience of the system to incorrect input, performance, quality attributes such as usability and documentation. You must also build in procedures for dealing with changes during the operational life of the system, to address any residual faults and the need for improvements over time.

Contractual scenarios

Typical approaches to contract for the development of information systems are:

• low-level requirements specification - the boundary between customer and provider is drawn between the detailed requirements specification and physical design. All the requirements that have an impact on the user have been specified in detail by the customer, giving the provider a very clear and precise implementation target. However, there is increased specification effort for the customer (who may not have appropriate skills) and the added value of the provider is restricted to the less difficult aspects of development
• high level requirements specification - the customer/provider boundary is drawn between the high level problem definition and detailed requirements specification. The provider contract covers everything below the line. The customer is responsible for testing the delivered system against the problem definition (that is, the business requirements), not the information system requirements. It is easier to specify requirements in terms of business outcomes and testing against requirements at this level could be seen as the only way of ensuring that the system meets the business requirements; there is also the reduced effort to develop contract inputs. However, there may be significant problems of increased cost and risk for both customer and provider, together with increased room for mistakes, instability of requirements and increased difficulty in knowing what information systems you want
• shared requirements specification (the partnership model) - with this model there are two contracts. The scope of the first, where the customer leads, covers the transformation of the outline problem definition to a formal requirements specification. The second contract, where the provider leads, transforms the specification into a delivered system. In practice, separate contracts are unnecessary, so long as there is a break point after the production of the specification. Requirements against which the final system can be measured evolve within the contract, rather than having to be established beforehand. The major advantage of this evolutionary approach is that it avoids the 'change vs refinement' argument between customer and provider.

Risks

The process model adopted for any system development is determined by the costs and risks of the project. The higher the costs and risks, the more rigorous the techniques used to control the risk. Development projects should always make extensive use of formal methods, expert inspections, prototyping etc to reduce the risks of fundamental errors. (See the Risk Management Guidelines, Managing programme and project risk.)

Estimating

The estimating process is primarily concerned with project scale; that is, the time and cost involved in specifying, designing, developing, delivering and installing, and sometimes also in operating and maintaining software, hardware, communications and other elements which together make up an IS project. The estimates are derived from the complex relationships which exist between:

• the proposed solution to the project requirement
• the nature of activities required to deliver the solution
• the range of human skills and capabilities these activities demand
• the availability and cost of human resources necessary to undertake the activities
• the productivity and efficiency of the people nominated for the work
• the tools and consumables needed to support the work
• the management and other 'overheads' necessary to direct the work.

Project planners will need to take all these factors into account to achieve the optimum balance of timescales and resources where no simple relationship exists. For example, doubling the size of a programming team does not necessarily halve the time taken to complete a given task.

Software lifecycle support

System development is only one part of the software lifecycle. The IT Infrastructure Library (ITIL) describes a standard set of activities for software lifecycle support. The key processes are:

• applications specification - a detailed study with users to establish what is needed
• applications development - includes testing and acceptance of system, must consider integration issues with possible current system infrastructure/software
• applications maintenance - modification of system after delivery, to correct faults, improve performance, adapt to changing business requirements
• decommissioning - the end of the system's useful life.

Quality management activities should take place throughout the system lifecycle - these are built into the design, selection and management of IS products and services.

Security must be considered throughout the system lifecycle. The CCTA Risk Analysis and Management Method (CRAMM) provides a structured approach to the identification of the protective measures required for IT systems. CRAMM should be used:

• during the system development process for determining security features
• throughout the operational lifecycle of the system at regular predetermined intervals to ensure continued protection
• whenever any alteration is made to the software system including software enhancements.

Detailed step by step guidance can also be found in the Requirements Workbook (PDF).