Requirements management

Requirements management is concerned with meeting the needs of end users through identifying and specifying what they need. Requirements may be focused on outcomes (e.g. describing what people should be able to do as a result of commissioning a new building) where the main concern is to describe what is wanted rather than how it should be delivered. Or the requirements may need to be specified in precise terms (e.g. when ordering a technical component to fit with existing office machinery). Or requirements may be described in any way between these two extremes. The important issue is that those specifying the requirement have an adequate understanding of what the users need and how the market is likely to meet that need; they also need to be able to keep any changes to the requirement to an appropriate minimum and to document the requirement in such a way that the market will be able to understand what is required.

This briefing is in draft form and currently focuses on elicitation of IT requirements. In the next version it will cover a wider definition of requirements management and links to guidance on the various forms of specification.

Requirements are capabilities and objectives to which any product or service must conform and are common to all development and other engineering activities. Requirements management is the process of eliciting, documenting, organising, and tracking requirements and communicating this information across the various stakeholders and the project team. It ensures that iterative refinements and unanticipated changes are dealt with during the project life-cycle, with a view towards the overall quality of the resultant service or product.

Further Information / Related Topics e.g. Roles / Techniques / Skills

In software engineering, the software requirements specification (SRS) is a primary concern for the software developer. It defines the complete external characteristics of the system to be built, including the behavioural characteristics, e.g. this system shall do X when the environment does Y, and non-behavioural characteristics, e.g. the system shall have an availability of 99.99%.

There are numerous software specification standards that can be used as a starting point in drafting an SRS. For example IEEE/ANSI 830-1993, 'IEEE Recommended Practice for Software Requirements Specifications', provides both guidance and flexibility.

A compilation by M. Dorfman & R. Thayer provides 26 different requirements specifications covering national, international, IEEE, ANSI, NASA, and US Military standards. ('Standards Guidelines and Examples of System and Software Requirements Engineering', IEEE Computer Society. 1991.)

Processes

Key aspects of the process are:

• Context - the organisational setting in which the requirements are emerging. It should be recognised that all requirements have attributes that are a rich source of management information. Each project should select the attributes that are critical to its success. For example: customer benefit, effort, development priority etc.
• Requirements elicitation - understanding the boundaries, ascertaining who are the stakeholders, recognising goals, using scenarios, feasibility, and risks
• Modelling and analysis - techniques that can be employed at the enterprise, data, behaviour, and domain levels
• Communications - use of appropriate language, documentation, and other formalisms to maintain appropriate dialogue and understanding amongst stakeholders. Also ensuring that requirements are traceable
• Agreements - validation, negotiation, conflict resolution and prioritisation of requirements
• Evolution - ensuring that the solution to meeting the requirements is responsive to environmental change and that such changes (in requirements) can also be managed and controlled effectively (involves impact analysis and configuration management).

The Requirements Workbook also presents related relevant information in a detailed step by step format.

Principles

Typically requirements start out in an abstract form and as exploration continues they become more specific, more detailed, and less ambiguous. Elicitation may occur using a variety of techniques, such as interviews, brainstorming, questionnaires, and quality function deployment or other techniques.

During elicitation, modelling and analysis, requirements may split and recombine in new ways as a set of detailed requirements emerges. Once captured, it is important to maintain a trace of each requirement from the more abstract predecessor(s) and also to the more detailed successor or implementation. Traceability facilitates change management and is a fundamental component of quality assurance and effective requirements management.

The most detailed level of requirements are usually itemised with a Requirements Specification. The specification should be made available to, and agreed by all relevant parties. The specification forms the basis of any design and is also used for test planning and test specification.

A requirements specification should exhibit the following characteristics:

• Lack of ambiguity - the requirements should be described in such a manner that it avoids multiple interpretations
• completeness - it may be impossible to second-guess future requirements, but at least known requirements should be specified
• Consistency - there are problems in defining and realising solutions that satisfy requirements if there are conflicting requirements.
• Traceability - the source of each requirement should be identified and should be traceable throughout the project life-cycle.
• Absence of design - as long as requirements address external behaviour as viewed by users or other interfaces, they are still requirements regardless of the level of detail. Requirements should not attempt to specify design information.
• Enumerated requirements - most requirements specifications enhance their readability by including auxiliary types of information that are not requirements. Actual requirements contained within the specification document should be discernible.

In managing requirements, the needs of requirements engineers should be recognised. For example, at the macro level a holistic view and detailed understanding of the whole system or artefact is required in order to provide a quick response to any evolution of requirements. This holistic view may be represented in models of the system or artefact, with an emphasis on representing all perspectives or attributes that are deemed important, e.g. configuration items/assets, people, processes etc. A flexible architecture should be sought also, which enables a more rapid response to evolution of requirements and for facilitating change.

At the micro-level sufficient attention should be given to quality attributes, including testability and reliability. The .ilities often present possibly overlapping requirements that can affect the cost of the solution and present architectural problems with respect to change in requirements.

Who is involved?

The key players involved in requirements management include: project management and engineering team members, customers, users, and other stakeholders.

Project managers are concerned with planning, budgeting, resourcing and scheduling the project. Knowledge of the requirements is essential for detailed planning and estimation purposes. Furthermore, in managing risks and gauging the impact of changes, requirements traceability is particularly valuable in mapping requirements to service or product features.

Analysts and engineers with relevant business domain knowledge should play an active role in eliciting and analysing requirements. They may work with customers, users and stakeholders to provide requirement models or other visualisations that may facilitate in the communication of the detailed requirements and in ratifying the proposed solution.

Testers and quality assurance personnel will also have an active interest in requirements in terms of testability and mapping the requirements through the various development stages.

Success Factors

For requirements management to be effective a number of issues need to be addressed, namely: refinement of requirements, levels of detail of documentation, and constraint management, including time-scales and resource levels.

Project managers should ensure:

• goal congruence amongst all the parties involved, for example: customers, business analysts, developers, designers, quality assurance, and end-users.
• that their plans allow sufficient time and have suitable resources committed to requirements elicitation and management.

Customers/users and other stakeholders may ultimately be concerned with outcome; however they need to understand:

• the importance of clear, specific and detailed communications with the project on requirement issues
• the importance of project requirements documentation
• the need to meet frequently with developers.

They should ensure also, that the documentation expresses their requirements accurately and they are willing and able to disseminate their domain knowledge in order that the development team can more readily understand the business processes and needs, especially during the planning, design and development phases

It is important that a common 'language' is established for expression of requirements, and to effectively communicate problems and issues. Project management should consider these aspects as an integral part of their decisions regarding the use of tools and techniques by the project team.

By selecting and using appropriate methods, tools and techniques for both project management and requirements management, the project team should be able to gain valuable insights from the stakeholders and ensure that their vision, the project purpose and tasks are visible to all stakeholders and remain clear. Early prototypes, design mock-ups, and graphical representations are useful vehicles for communicating ideas and for gathering specific customer requirements.

A collaborative approach on the part of customers, users and the project development team is often considered to be of benefit. Such  collaborations should be aimed at lowering development costs and improving project success rate through understanding clearly user requirements, and anticipating changes.

Clearly, being able to respond to the rapid evolution of requirements is a critical success factor. This requires a holistic perspective and a detailed understanding of the whole system or other artefact.

The drivers for change

A customer may be concerned with outcomes, in terms of a particular procurement. However, if what is wanted by the customer and other stakeholders is never defined, it should be no surprise that they may receive unsatisfactory products and services.

The development of large, complex systems and services, and indeed the completion of major construction projects can provide many challenges to the engineers involved. A key aspect being to assure that the final service or product satisfies the needs of the customers and users and provides for easy maintenance, evolution and enhancement during the deployed lifetime. Change in requirements and evolution of the product or service through even the development life-cycle, can make it difficult to trace the implemented constructs against the original and evolving requirements.

From the suppliers' or service providers' perspective, a development project manager needs to be confident that they are producing appropriate deliverables, and requirements management helps them to do this.

Requirements enable an understanding of customer and user needs, and facilitate a dialogue about these needs. They also provide a base-line on which the success of the project or implementation of the service can be measured.

Requirements management necessitates that information is captured, stored, managed and disseminated.

There are a number of causes of poor requirements elicitation that need to be addressed by requirements management, including:

• Customers overlooking the importance of documenting the detailed requirement, as a precursor to development activities
• Premature development - in which development work is undertaken before the requirements are sufficiently understood by both the customer and the project team
• Communication problems - difficulties can be experienced through a lack of a common 'language' between customers and the project team.
• Customers discovering new or different features during project implementation.
• Sudden or unplanned changes taking place in the business process or customer needs.

In managing requirements, due regard needs to be given to organising requirements information, traceability, analysis, and visualisation. Requirements traceability, often supported by requirements management tool-sets, provides information on the relationships between requirements, design and implementation, and can facilitate the management of change through impact analysis to ensure any change in requirements will not adversely affect the successful delivery of the product or service.

Key questions that can be addressed through traceability as part of an effective requirements management process, include:

• Ascertaining the impact of changing a requirement
• Ascertaining where a requirements are implemented
• Assuring that all requirements are allocated to some aspect of the design and are present in the overall product
• Establishing what need is satisfied by a particular requirement and/or why the requirements needs to be addressed
• Discovering what design decision affect the implementation of a requirement
• Understanding why a design has been implemented in a particular way and what were the alternatives
• Verifying that the implementation is compliant with the requirements
• Deciding what acceptance tests are necessary

Why we need to change (Why it is important)

A general survey of some 300 projects across car manufacturing, telecoms and aerospace industries indicated that the main cause of failures were management and requirements issues. Five of the top eight issues were related to poor handling of requirements.

For software projects, according to the Standish Group, 31% of software projects are cancelled before the product is delivered to the customers, while 53% cost 189% or more of their original budgets. 40-60% of the software defects and failures being attributed to poor requirements, thus reflecting extent of the problem and the need to identify, communicate and manage IS project requirements.

A project that fulfils its requirements is by definition a success. Requirements management ensures that suitable models of the service product are produced early in the life-cycle in order to provide fresh insights and to improve the conceptualisation of the end product or service.

Requirements management starts with the definition of requirements and continues through the project, culminating in the verification of the end product against the specified requirements.

Requirements management has a strong association with quality management in ascertaining what the customer wants (quality) and evaluating the solution in terms of whether it meets these requirements efficiently (conformance).

What is it?

Requirements management is concerned with understanding the goals of the organisation and its customers and the transformation of these goals into potential functions and constraints applicable to the development and evolution of products and services. It involves understanding the relationship between goals, functions and constraints in terms of the specification of products, including systems behaviour, and service definition.

The goals provide the motivation for programmes and projects and represent the 'why' and to a certain extent the 'what' in development terms. The specification provides the basis for analysing requirements, validating that they are indeed what stakeholders want, defining what needs to be delivered, and verifying the resultant developed product or service.

Requirements management aims to establish a common understanding between the customer and other stakeholders and the project team(s) that will be addressing the requirements at an early stage in the project life-cycle and maintain control by establishing suitable base-lines for both development and management use.