10 Deciding the requiremenTs approach

This chapter covers the following topics:

• the requirements engineering framework;

• planning the requirements approach;

• issues with requirements engineering;

• agile requirements elicitation;

• requirements elicitation techniques;

• the role of business analysis in elicitation.

Introduction

Understanding the customers’ requirements is a major area of business analysis activity, which requires careful consideration at the outset of a change project. This involves determining how the requirements are to be elicited, and the extent to which they will be defined. While detailed requirements are expected to evolve during agile software development, this is also the case for the other areas of the solution, for example, the requirements that are to be met by business process changes. However, there remains a need for a clear definition of the high-level requirements that provide the context for the change project.

This chapter considers a means of determining the requirements approach and how the requirements engineering framework may be adapted and applied within an agile project.

THE REQUIREMENTS ENGINEERING FRAMEWORK

Requirements engineering is a framework for obtaining, defining and managing good quality requirements. There are some fundamental stages of requirements engineering that need to be understood and utilised within any project and these stages are defined in the requirements engineering framework shown in Figure 10.1. Deciding the approach to requirements engineering will vary, depending on several factors that may include the project scope, complexity of the project, budget and resources available and expected business outcomes. A framework, such as that provided in Figure 10.1, is only a starting point as all projects are different and it should not be assumed that one requirements engineering approach will be suitable for all.

 

Figure 10.1 Requirements engineering framework

Looking at each stage within the requirements engineering framework allows us to explore their use and validity within an agile approach as follows:

Elicitation		The requirement is identified through collaboration with stakeholders. In the early stages of a change project, the elicitation activity may have a wide scope, typically by focusing on higher-level business requirements, and limited detail. As the project progresses, the requirements elicitation work may take a more detailed approach, concentrating on a narrower scope. Elicitation is an iterative and enduring activity that takes place throughout a project.
Analysis		Requirements are analysed to determine whether they are relevant, realistic, ambiguous in any way, can be tested, contribute to business goals, or overlap or conflict with other requirements. The priority level for each requirement is agreed with the appropriate stakeholders. Modelling requirements can assist the analysis activity. For example, a system use case diagram provides a means of understanding the outline scope of the required system and the actors who are interested in the system features. This helps put the requirements in context, ensuring that a fragmented picture is avoided and supporting both iterative development and incremental delivery. It also provides a summary visualisation of the functional requirements and avoids the need for lengthy textual descriptions. Other models may also be used to help in the analysis of areas such as data, interface and processing requirements.
Validation		Requirements are validated by review, typically using visual techniques such as prototypes and models; these may take the form of physical or automated prototypes or diagrams. In the early stages of a project, requirements validation may focus on agreeing an outline scope and a set of initial, business requirements that provide a basis for further elaboration. When using agile, a requirement is not validated until it is ‘in use’ and may be demonstrated within a working solution provided by new or improved processes or software.
Documentation		Requirements need to be documented to clarify what it is that the business wants the solution to provide. However, the amount of detail in the documentation depends on factors such as the levels of complexity and priority. Further, the detail of the requirement description is likely to increase as the time for implementing the requirement draws near. The level of requirements documentation needs to be decided by the project team and should be minimised such that it is ‘just enough’ to enable the project team to plan, design and develop working solutions. It is important to distinguish between requirements documentation and system design documentation. Accurate system design documentation is concerned with the way in which the requirements are delivered, so should reflect the working software rather than the requirements.
Management		Once documented, requirements must be managed. A ‘just enough’ approach to documenting requirements minimises the amount of management. Managing requirements includes agreeing such things as where agreed requirements will be stored, how the link between solution requirements and the business objectives and project goals is ensured, and how they should be organised. Traceability of requirements is an important area that needs particular consideration when working on an agile project. The extent to which traceability is required should be considered before putting in place any mechanisms to enable traceability. It is also the case that the potential for ensuring traceability will be affected by the documentation approach selected. For example, if it is decided to document the general requirements in a list and to use a model such as a use case diagram to document the scope of the system requirements, it may be sufficient to adopt the following approach (also see Figure 13.1): • Vertical traceability: for each use case, define which general requirement is supported. • Horizontal traceability: for each general requirement and use case, document who raised each requirement and the status (such as when it will be delivered). Consideration should also be given to the extent to which changes to the requirements should be recorded. It is the nature of general requirements, which are focused on stating policy constraints and identifying business objectives, that they remain relatively static. However, at a solution level, where the requirement descriptions comprise detailed definitions, this is rarely the case. Where it is felt that a requirement needs to be documented in specific detail, it will be necessary to ensure that the documentation is maintained in line with any changes made. However, in an agile environment it is typically the case that solution requirements are described as outline features and the detail is elaborated during the development of the solution. In this case, the changes that need to be recorded and linked to the documentation are those that affect the outline descriptions. Otherwise, the view may be taken that the exploration of detail involves exploring various options and that the requirement does not change but has evolved as greater understanding is achieved.

Requirements slices

The application of the requirements engineering framework is determined by the solution development approach adopted. A linear approach would require each stage to be undertaken in depth to ensure that a comprehensive requirements document is produced. An agile approach necessitates iterative development and incremental delivery and may result in revisiting each stage many times as the requirements evolve and are further understood, decomposed and prioritised. It is still important that each of the stages is undertaken when using agile, but the extent to which this is done, the techniques applied and the required outcomes, will differ.

One way of considering this is to think of applying the requirements engineering framework in ‘horizontal slices’ as shown in Figure 10.2. At an initial stage, such as a feasibility or pre-project analysis, the focus may be on eliciting and defining the general requirements, with less emphasis on the solution requirements. This reflects that there is little point in elaborating all the solution requirements in considerable depth at an early stage, as it is likely that the details will be subject to change. The next ‘slice’ may then be concerned with a subset of the initial requirements so that the relevant solution requirements are elaborated to the level required for further development. This can continue through several slices in line with the number of increments required to deliver the entire solution.

It is likely to be the case that more effort is expended initially on elicitation, with less spent on the other stages. Similarly, more analysis may be carried out in a later iteration once the scope and context is understood. Initial collaborations with stakeholders typically result in the elicitation of requirements, which are then recorded in outline only. During the next iteration, a subset of the elicited requirements will need to be analysed and this may require a detailed analysis of the selected set, depending upon the characteristics of each requirement. For example, where a set of requirements is concerned with delivering features that contain complex calculations, an analysis of the business rules at an early stage will be beneficial to the project.

 

Figure 10.2 Slices of requirements engineering applied iteratively

During each of the ‘slices’ the approach to documenting requirements may differ, with some requiring more detail than others. Similarly, the extent to which validation and management of the requirements is needed will need to be determined. This is discussed below.

In contrast, a project following a more linear approach may spend more time in each stage sequentially and therefore the slices will be much deeper and there will be fewer of them, with maybe only two or three slices per project whereas an agile project may have far more horizontal slices.

PLANNING THE REQUIREMENTS APPROACH

It is prudent to plan the requirements engineering work so that all participants are agreed on an approach that will meet their needs. There are three aspects to consider: the level of detail of the requirements documentation, the types of documentation to be created and the timing of its production. To do this, the purpose of the requirements artefacts needs to be considered; there is little benefit to be gained from producing models or other documents that no one is likely to use or understand. When documentation should be produced will relate directly to the selection of the requirements for development. Until this point, there is little benefit to be gained from documenting the requirements in any detail.

When planning requirements, it is useful to consider the following questions:

• Are the scope of the solution and business goals well understood?

• Are there business or technical constraints that need to be considered?

• Are the different POPIT™ elements for the proposed solution understood?

• Who will use the requirements and/or models?

• What format should be used for the requirements or models to meet the project needs?

• Do the requirements or models need to be kept up to date?

• How long do the requirements or models need to be retained?

A useful tool to help with the planning of requirements is the simplified FMM introduced in Chapter 6. Figure 10.3 sets out a planned approach to the requirements artefacts and shows how the simplified FMM can be used to develop the requirements approach.

 

Figure 10.3 A suggested FMM plan for the requirements approach

The simplified FMM is an excellent tool to plan how the requirements will be captured and recorded at each level. This will vary from project to project and will depend on factors such as the size and complexity of the project as well as the nature of the organisation. It is important to note that this planning must be done in conjunction with the development team, who will utilise the defined requirements, and the customer, who will need to collaborate to ensure that the delivered solution offers value to the business.