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.
ISSUES WITH REQUIREMENTS ENGINEERING
Requirements engineering encompasses the core business analysis skills of requirements elicitation, analysis and definition. The term ‘elicitation’ is used advisedly in this framework, as it puts the onus on the analyst to work collaboratively with customers to uncover requirements rather than expect that they will be readily available. Most stakeholders will not know what they require without assistance, so requirements are elicited, rather than gathered, and this task needs considerable expertise. Requirements elicitation is the first stage in the requirements engineering framework in Figure 10.1.
It is very hard to express up front and in full detail something that you have never had or experienced. Sometimes stakeholders think they have a clear idea about what they want but often the focus is on a solution rather than the underlying requirements. It is part of the business analysis skill set to be able to challenge and analyse stated requirements, and assess the impact of proposed changes, to ensure that accurate and relevant requirements are defined. While it is possible to provide ideas initially, requirements tend to change as the project progresses and understanding evolves and deepens. For this reason, the requirements for an agile change project are not defined in their entirety at the outset; they are elaborated when required, typically in subsets that are allocated to an iteration for development.
The traditional approach to requirements engineering, shown here in Figure 10.4, can be ineffective for projects today.
Figure 10.4 Traditional approach to requirements engineering
Figure 10.4 shows how requirements engineering may be concentrated at the beginning of a project and the results captured and signed-off in the requirements document. Not only is arriving at a complete, consistent and agreed specification difficult, but there is a high risk that much time will be spent changing and updating the requirements during the rest of the project. As requirements change, as many of the detailed solution requirements inevitably will, change control processes must be implemented to manage the changes and this can be very time consuming. If we analyse this approach to requirements definition and change control using three of the Lean ‘wastes’, we can identify the following issues:
• Overproduction: requirements are elicited, analysed and recorded too early and in too much detail.
• Inventory: there has to be an investment in time for recording and managing the requirements in order to keep them up to date.
• Overprocessing: applying tighter tolerances in the approval and sign-off procedures than is necessary. Getting formal approvals carried out, all of which may be in vain if/when the requirements change.
To combat some of these problems we need to consider a different approach to requirements engineering.
AGILE REQUIREMENTS ENGINEERING
For some agile projects, requirements definition can be straightforward, involving discussion and collaboration with one customer representative who is the ‘voice of the customer’. Unfortunately, most projects are more complicated. As discussed in Chapter 7, there are typically many different customers and stakeholders to consider, all of whom have different views on what the solution needs to achieve. Understanding those individual views and forming them into something that customers and stakeholders can agree on requires extensive analytical and interpersonal skills. There is also a need for ongoing engagement to gain buy-in from the wider stakeholder group.
There may be problems with requirements engineering within agile development projects, as often the skills needed to do this work are lacking within the development team. One reason for these problems relates to the over-simplistic role titles, such as ‘development team’ or ‘product owner’, that are used in some methods. These titles do not help to clarify the skill set needed from those working on the project and can imply that the primary focus is on the software development. However, software features or software products should not be the focus of the development; as discussed in Chapter 6, the focus should be on the required business outcomes. If skilled business analysts are not available or involved, requirements engineering can end up being carried out by individuals who have the responsibility for this work but little practical experience. If the product owner has little or no business analysis experience or training and is left to conduct the requirements work, it is unlikely that the results will be satisfactory. Some typical issues that arise when agile teams conduct requirements engineering are:
• failing to undertake stakeholder analysis and missing key stakeholders;
• putting complete trust in one person to represent the ‘voice of the customer’;
• failing to engage with the wider stakeholder group and understand the different requirement viewpoints;
• focusing too much on eliciting functionality and features and ignoring the non-functional requirements;
• failing to analyse how the new solution will change current working practices, job roles, management structures and business processes.
Defining requirements for agile projects requires a different approach which is shown in Figure 10.5.
Figure 10.5 An agile approach to eliciting requirements
Figure 10.5 shows how the requirements elicitation and analysis needs to be ongoing, aligned to the iterations of the project and the requirements engineering horizontal slices described earlier. Sign-off happens at the end of each iteration and increment and it is the working solution, in the form of MVPs or the MMP, that are signed off, not the requirements document. This means that the requirements don’t have to be fully specified in advance, but can be ideas that evolve and change over time. In this way, the requirements are emergent during the development process. The development team are responsible for building the solution that delivers the requirements, so will bring their skills and ideas to the development process. Within an agile project, they can engage and collaborate with the stakeholders and thus explore the potential and viability of these ideas. For example, do they offer positive outcomes for the customer?
Figure 10.5 does not show a specific business analyst role but there is an abundance of business analysis taking place; not all projects have designated business analysts, but they all need business analysis to be done. In this example, requirements engineering doesn’t just happen at the start of the project, it is ongoing throughout because as the first ideas are formed, understood and prioritised, they give rise to new ideas that again need to be elicited and analysed. In this sense, requirements engineering is an iterative process that ebbs and flows along with the iterative and incremental heartbeat of the project.
REQUIREMENTS ELICITATION TECHNIQUES
It is important to employ elicitation techniques that will combat some of the problems that can arise during requirements elicitation on agile projects. Requirements elicitation helps business analysts to understand who to engage with, the problem to be solved, and which goals to prioritise and meet first. If this is not done, we could end up delivering a poor or limited solution. The use of facilitated workshops, involving a small group of business users with the aim of developing user stories, is an extremely popular approach for agile projects. However, this approach may not overcome the issues identified earlier and needs to be supported by other techniques.
Agile requirements evolve throughout the project and so it makes sense that we have a set of techniques for eliciting them that can be applied continuously. This is an iterative approach, where the high-level requirements are explored to uncover the detail needed to develop the solution. Table 10.1 explains the most useful techniques for evolving requirements iteratively.
Table 10.1 Techniques for evolving requirements iteratively
| User interview |
User interviews are still the most widely used technique in requirements engineering work; they provide a means of eliciting a great deal of useful information. While agile approaches focus on collaborative working, there is still merit in conducting one-to-one interviews to: • build rapport and trust with stakeholders; • identify individual stakeholder perspectives or even personal agendas; • highlight organisational politics; • understand how things work currently and where the issues lie; • understand the landscape for the change; • clarify the business goals to be achieved. |
|
| Survey/questionnaire | Surveys can be useful to obtain specific information from a large group of stakeholders where interviewing individuals, or possibly running a series of workshops, would not be practical or cost effective. For example, where there is a user story that has a large user population, it can be helpful to use a questionnaire to research answers to a specific question or to gain user input on the level of priority. | |
| Observation |
Observing the work in operation is an excellent way of clarifying or eliciting new requirements as follows: • understanding the order in which the work is done; • identifying where there are potential improvements in a process or software product; • highlighting where tacit knowledge exists. |
|
| Story-writing workshop | A story-writing workshop is probably the primary method of obtaining user stories and should include developers, users and the product customer. Business analysts may contribute to the story writing or facilitate the workshop. The story-writing workshop is the most effective way to quickly identify stories and is discussed further in Chapter 12. | |
| Scenario |
Scenarios draw out detailed requirements that include: • sequencing and order; • ‘what if’ analysis; • hidden business rules; • data constraints; • exceptional conditions. Scenarios are covered in more detail in Chapter 12. |
|
| Prototyping | Prototyping is one of the core techniques used within agile development to elicit new requirements. This is because prototyping is a way of visualising the requirements, whether using a low fidelity storyboard or working software. Prototypes help in the elicitation of requirements to improve or change the behaviour, look and feel or functionality of the solution. These are valuable requirements that would be hard to elicit in the early stages of a project. Prototyping is discussed further below. |
Prototyping
Prototyping plays a large role in agile software development and can also be used to visualise other elements of the holistic solution. It is an elicitation technique because it unearths new requirements that are often identified through the use of the prototype. There are a range of prototyping approaches that can be used for different projects and deciding which one to use relates to the nature of the project and the solution under development. Where part of the solution involves a process, there may be a need to prototype forms or reports; where the prototype relates to a software solution, there may be prototypes of the user interface or of the internal functionality. It can be instructive to consider where the greatest risks lie and use prototyping to confirm or correct the proposed solution approach. There are two categories of prototype: throwaway and evolutionary.
The prototype is developed for the sole purpose of eliciting or analysing requirements where there is a lack of clarity, for example, where the project is in its early scoping phase. Throwaway prototypes can be low fidelity, perhaps a flip chart with sticky notes or a PowerPoint mock-up of a wireframe, or may be high fidelity using more sophisticated software packages. Whether high or low fidelity, the throwaway prototype is discarded after it has served its purpose. |
||
Evolutionary |
The prototype evolves as the project progresses. Early working prototypes are used to gain more concrete understanding and are then further developed, tested, implemented and adapted as greater understanding develops. |
Scenarios and prototyping are often used in tandem when eliciting and analysing interface requirements for software systems. Each step within a scenario represents an interaction between the user and the system. The interface displays instructions, captures data and presents information. The prototype helps in the elicitation of the presentational layout and the data requirements. A low fidelity throwaway prototype for a scenario where a customer registers an account is shown in Figure 10.6.
Figure 10.6 A low fidelity throwaway prototype
This type of prototype helps business analysts to present a visualisation of the scenario to the business user and work collaboratively to define the data, information and usability requirements. The additional benefits of a prototype such as this is that it is quick to create and change.
THE ROLE OF BUSINESS ANALYSIS IN ELICITATION
Not all organisations have dedicated and experienced business analysts. However, in every organisation and on every project, whether it is an IT or business change project, business analysis is needed to elicit requirements effectively. The business analyst role was originally developed to bridge the gap between business users and developers. However, where a collaborative team is working on an agile project, it is important that the business analyst does not act as a ‘translator’, speaking on behalf of the customers or the developers, as this has the potential to introduce bottlenecks or errors to the process. Figure 10.7 represents this situation.
Figure 10.7 Business analyst standing between customer and development team
Historically, there has been a separation between the technical staff and the user community on IT projects due to an assumption that communication between these two groups is problematic. While there may have been some situations where this assumption has been proven to be correct, agile development teams seek to engage T-shaped professionals (see Chapter 7) who work collaboratively towards a common business outcome. This approach helps everyone to develop a range of skills that will improve communication between the specialist disciplines. There is a role for the business analyst in this process, which involves facilitating discussions and clarifying any points of confusion. This role is represented in Figure 10.8.
Figure 10.8 The business analyst role in facilitating collaboration
Where there are no dedicated business analysts on a project, this facilitation role will still be required. It may be performed by members of the development team (where they have the requisite skills) or it could be done by a business representative, such as the product owner or even the project sponsor.
CONCLUSION
It is imperative that the agile business analyst understands that a ‘one-size-fits-all’ approach to requirements engineering is not effective. Deciding the correct approach requires business analysts to understand the business requirements so that horizontal requirement ‘slices’ can be selected and elaborated in order to deliver increments of the working solution at an early stage. This will help to prove or disprove any assumptions and achieve the desired outcomes for the business.
Elicitation techniques help business analysts ensure that the right solution is developed and delivered. Without sound elicitation, the project could miss tacit knowledge, make assumptions and deliver solutions that meet what the customer wants, but not what the customer needs.
As individuals employed within agile teams accept that they need to become T-shaped professionals, there is a concern that business analysis skills may be overlooked. This would be to the detriment of delivered business solutions, as it is clear that customers need help to uncover and elaborate their requirements. This requires the support of professionals with business analysis skills but if there are no business analysts working on a project, the responsibility for this work will need to pass to other members of the development team. Whichever is the case, business analysis is needed to define the requirements to the extent needed by the project to ensure that working solutions that offer benefits to the business are delivered.
FURTHER READING
Cadle, J. (ed.) (2014) Developing information systems. Swindon: BCS.
Cadle, J., Paul, D. and Turner, P. (2014) Business analysis techniques. Swindon: BCS.
Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.