This chapter covers the following topics:

INTRODUCTION

Business analysts may be involved in many different types of project. For example, software development, process change, capability uplift or hybrid projects that encompass many different aspects. Whatever the project, there will be a business context that provides a rationale for the change and some high-level business requirements that form a backdrop for the project against which more detailed requirements may evolve. Prioritisation (see Chapter 9) plays an important part in determining which projects within the analysis portfolio are enacted and, within projects, which business requirements are included within the initial solutions delivered to the business.

Understanding the business context for a change project is vital. Without business analysis to determine the nature of the problem to be solved or the opportunity to be grasped, and without understanding of the high-level business requirements, there is a risk of a myriad of detailed requirements being raised in a fragmented and inconsistent manner. To overcome this possibility, there has to be some early understanding and documenting of the business context and the business needs to be addressed. This does not mean that every last detail of every business requirement has to be documented and cross-referenced; it does mean, however, that an agile business analyst needs to ensure that there is sufficient documentation containing the required level of detail. This requires business analysts to work closely with their business customers, using their domain knowledge and analytical skills to uncover where effort needs to be expended and at what point.

Managing the requirements is also important so that those with the potential to offer value at an early stage or overcome an urgent problem are progressed first, while other aspects to be tackled at a later stage are recognised and not overlooked. Also, changes to the high-level scoping requirements need to be expected and processes to handle such changes must be embedded within the project approach. Having said this, it is also important to recognise that there is little point in documenting and managing requirements purely for the sake of producing and controlling documentation; there has to be a genuine need to be addressed and the approach adopted has to be sufficient to address this need. Understanding the levels of requirements definition, the different ways in which requirements may be documented and the alternative governance mechanisms will help business analysts to deliver beneficial solutions at the earliest stage possible. This is explored further in Chapter 11.

This chapter looks specifically at the different types of requirements and the requirements hierarchy and explores their value in an agile change project; it also discusses the different ways requirements can be recorded and managed.

TYPES OF REQUIREMENT

One of the commonly used structures distinguishes between the four different types of requirement shown in Figure 13.1 below: general, technical, functional and non-functional requirements.

 

Figure 13.1 Types of requirement

The rationale for these categories is that each one focuses on different aspects of a solution, with the business and technical requirements providing strategic and architectural contexts for the solution. The four types of requirement are described below.

General requirements	These are the overview general requirements to be addressed by the solution. Some of these requirements may be enforced by law, for example, regulatory requirements. Others may be internal policy, for example, marketing or branding requirements. Other general requirements may concern requests from senior business managers, for example, for a new service offering. Some general requirements offer a composite view of desired features or functional requirements and need to be decomposed when considering the solution in further detail. The general requirements set out the context for the change project. Some – such as those setting out compliance or policy requirements – may have been defined for the entire organisation during a previous project and therefore may be reusable. However, these requirements are still subject to prioritisation and it is often the case that they are the most important requirements to prioritise because they indicate where effort should be focused and at what point. Some of these requirements may have been suggested by stakeholders without consideration of cost or feasibility or impact. It is vital that business analysis is conducted to examine the rationale for each requirement and to determine whether there is a real business need to be addressed and the cost of doing so, the goal to be achieved in delivering the requirement and the urgency with which the requirement should be delivered.
Technical requirements	Most organisations have defined technical standards of one sort or another; the larger the organisation, the greater the likelihood of extensive technical standards. However, even the smallest of organisations is likely to have standardised on software for documentation and communication. An understanding of the technical constraints is an important aspect of a change project, as it could mean the difference between success and failure. There may be an entire technical infrastructure with selected hardware and software, networking and communication suppliers. There may be standards for data definition and transmission. Failing to understand these requirements could cause serious problems and delays. However, many of them are reusable so they should not have to be defined for each project. An agile business analyst needs to be aware of these requirements and ensure that previous definitions of technical constraints are used where possible.
Functional requirements	The functional requirements set out features and goals that should be met by the solution. A fundamental aspect of agile business analysis involves considering the most appropriate way to elicit, elaborate and record functional requirements. Functionality may be explored and documented in many ways, as set out in Chapters 11 and 12. For example, it may be helpful to analyse and model functionality using techniques such as use cases and user stories. These artefacts may be created at different levels, providing a clear link between the business need and the proposed solution. They also offer a means of recording the required features and the goals to be achieved by the solution. They show a clear link between the business and solution requirements when using these techniques. However, in some cases, a catalogue of requirements may be the most relevant approach. For example, if a project has a strong contractual basis, it may be necessary to list the requirements in a catalogue and clearly identify aspects such as the owner, the rationale and any cross-references to other project documents.
Non-functional requirements	Non-functional requirements define the level of service quality to be provided by the solution. They cover a range of areas, in particular: • access and security; • capacity and scalability; • availability, robustness and maintainability; • business continuity, backup and recovery; • performance and response; • deletion and archiving; • compatibility and interfacing; • accessibility and usability. These requirements may be recorded within the functional requirements documentation, such as where a non-functional requirement – for example the speed of the response – relates to a specific functional requirement to provide some information or take some action. An example might be in a restaurant, where an order must be taken within ten minutes of seating customers at a table. A non-functional requirement that is embedded within the description of a functional requirement is sometimes referred to as an associated non-functional requirement or could be written as detailed acceptance criteria using techniques such as BDD, as discussed in Chapter 12. Other non-functional requirements apply to several functional requirements and may be relevant across the entire solution. For example, wherever information or data is recorded or accessed, there may be an overarching requirement setting out the level of access available to different user roles. These requirements are sometimes referred to as system-wide or solution-wide non-functional requirements. The means of recording non-functional requirements needs to be considered carefully whatever the development approach to be used. However, this is particularly the case when working in an agile environment. This subject is considered in further detail later in this chapter.

THE REQUIREMENTS CATALOGUE

A catalogue is a central repository of information. It may encompass a list of services or products or any other item that needs to be listed and organised centrally. A requirements catalogue provides a central repository for requirements that have been identified for a particular change project and is typically organised such that requirements that have similarities are located together.

Each requirements catalogue entry records the information about a specific requirement. This information may include some of the following aspects for each requirement:

One of the frequent misconceptions about the requirements catalogue is that each entry has to be definitively and rigorously complete before the catalogue can be agreed. This misconception needs to be challenged, as in many circumstances it is not desirable, or even possible, to provide a detailed definition. A general requirement may be a high-level statement such as ‘the solution must use company branding standards’. In this case, there would be little point in spending time recording links to the potentially numerous related requirements; it just needs to be accepted that this will be applied whenever relevant to the solution. Similarly, technical constraints and some non-functional requirements, such as those related to accessibility and usability, have a solution-wide application and could be cross-referenced to many functional requirements. However, to do this would be a waste of time; understanding that these requirements are relevant to each development iteration would suffice.

It may also be the case that the requirements catalogue is used to record high-level functional requirements where the detail is defined using modelling approaches. So, we might define the following requirement: ‘the solution must record customer details’, but then use a data model to define what is meant by ‘customer details’. In the past, requirements catalogues have been used to contain as much narrative information as possible; information that has then been duplicated (and sometimes contradicted) in business process, use case and data models. This has meant that time has been spent on activities of little value and often areas of very low priority have been explored to the same level of detail as those that are absolutely essential. If we want to use a requirements catalogue, we need to ensure that it is used in an informed way, recording relevant information to support the development of the required solution.

Agile business analysis is founded on applying business analysis in line with the agile philosophy and principles. Documentation that is sufficient to the situation is a key element of this approach and the use of the requirements catalogue should be considered within this context. Agile projects may find it helpful to use a requirements catalogue for some categories of requirement – for example, the general requirements – because they provide a contextual view. However, it may be more beneficial to use an alternative approach such as a backlog of user stories to record areas of functionality requested by customers.

THE ITEMISED BACKLOGS

The concept of a backlog derives from the Scrum approach to software development. Each backlog provides a means of listing the work items to be conducted by the project during the development of the product. Hence, Scrum calls the backlog the ‘product backlog’. However, a software product is not sufficient to improve business; it needs to be deployed in conjunction with the other required changes to processes, jobs, skill enhancements and organisational changes.

Business analysis has always taken a holistic view, moving beyond focusing on software products to think about multi-faceted solutions to business problems or opportunities. In some situations, there may not be a need for software at all. For example, a simplification to a process might address a particular business problem and deliver the required benefits. Therefore, looking at the concept of a backlog from a business analysis perspective, a solution backlog containing a list of itemised requirements to be met, is more relevant. The solution backlog might relate purely to a software product but, in our experience, the chances of such a limited solution generating business improvements are low.

While the solution backlog contains the entire set of required work items, we also need to consider the use of backlogs in driving the solution development. There are two other backlogs to consider: the release backlog, which contains the work items that form the set of changes that are to be deployed into operation; and the iteration backlog, which lists the items to be worked on during a specific iteration. The release backlog contains the minimal set of items from the solution backlog that will offer value when delivered to the stakeholders. These three versions of the backlog are represented in Figure 13.2 below.

 

Figure 13.2 Three different views of the backlog

The solution backlog

The term ‘solution backlog’ reflects the business analysis world view that change projects focus on providing a solution that addresses a problem or grasps a business opportunity. The solution may involve a software product but invariably, for a business change to be successful, it may also encompass broader aspects such as people, process and organisational changes. Each of these aspects needs to be considered when scoping the proposed solution.

When the project is focused on software development, the backlog items drive the work of the software development team; this is the focus of agile methods such as Scrum and XP. However, as described in Chapter 3, business analysts are often involved in different aspects of change projects so may need to apply a broader, more holistic focus. In these situations, the backlog should reflect the need for the solution to encompass a range of areas. Business epics (discussed in Chapter 4) may be used to describe these work items. For example, where the project is concerned with business process change, the backlog items may include the following:

Once these items reach the level of priority where they are allocated to an iteration for further development, there will need to be collaboration and communication with business stakeholders in order to elaborate on the requirement and ensure that the needs are met. In doing this, business analysis is needed to investigate the requirement and ensure that there is a clear justification for the changes. This may involve challenging some of the detail provided by the business stakeholders to ensure that the root causes of any problems are uncovered and the actual issues, rather than the manifest symptoms, are addressed by the solution.

The solution backlog allows business analysts to think holistically about the elements to be included in the backlog and extend their focus beyond software development. The solution backlog has similarities to the requirements catalogue in that it provides a prioritised master list of the items to be considered for inclusion in the solution. It is also a living document in that it develops over time, beginning with an initial set of items and evolving as more detail of the required features emerges. It is prioritised using an approach to rank or categorise the items. Chapter 9 sets out the different prioritisation approaches that may be used to do this.

An accepted feature of the solution backlog – and possibly one of the key differences with the requirements catalogue approach – is that there is not a sense that the backlog is ‘signed off’ as a complete record of the requirements for the solution. Instead, it is accepted that there is further understanding needed and more details to uncover. The solution backlog should be maintained, and priorities adjusted, using a collaborative approach that involves the project team and the key business stakeholders.

The items recorded in a backlog may be of different types. For example, they may be functional requirements that set out what the solution must enable the customer to do. Or, they may be non-functional requirements that define the levels of quality to be offered by the solution. The functional features to be delivered as part of the solution may be defined using techniques such as use cases or user stories; the exact technique used will depend upon the situation as discussed in Chapter 11.

Ordering and reordering the solution backlog

The development of the solution requires the project team to explore the work items documented in the backlog. This work may cause additional items to be identified as the team explore the solution in further detail and this will require re-prioritisation of the backlog.

Where the work items are recorded user stories, they are used by the project team to evolve the understanding of what is to be delivered. This work may cause additional user stories to be generated, which are added to the backlog. The new user stories may be large or may be of a more manageable size and complexity. Adding new stories will require the re-prioritisation of the backlog so that the most important items are highlighted; this will ensure that they are incorporated within the next release or iteration. Therefore, there is an ongoing, iterative approach to prioritisation that will require collaboration with the business stakeholders. The aim of a business change project is to improve the work of an organisation or produce a marketable product that may be sold by the organisation. The work to achieve this requires ongoing awareness of the business context into which any solution will be delivered. As a result, business analysis is essential if decisions regarding prioritisation, ordering and selection of the backlog items are to be effective and in line with business needs. This ‘ordering and reordering’ of the backlog is also described in Chapter 15 and referred to as ‘product backlog refinement’.

The timing of the backlog ordering activity can be critical. It is possible to do this during an iteration, but this approach may deflect the project team from the work they are undertaking. However, if the business analyst is involved in the reordering activity, this would allow the work of the project team to continue while ensuring that the basis for deciding upon the next iteration is in place. A further benefit of the business analyst involvement in this activity is that it helps to ensure that the development work remains consistent with the original goals and business case for the project.

The release backlog

Solutions developed using an agile approach will be delivered in releases, or increments, and each increment may comprise a set of software features, process improvements and organisational changes. An increment may be developed during one or several iterations but essentially is delivered into operation once there is a set of changes that is internally consistent and will offer value to the customer organisation.

The release backlog is an important concept because it sets out what is to be delivered in the next increment. Therefore, it must be internally consistent and complete – there is little point in introducing a partial solution that requires significant effort to be spent on workarounds.

The iteration backlog

Each iteration needs to have a designated package of work items. These items should be subject to analysis, development and testing within the iteration and result in functionality that has the potential to be deployed. The backlog for the iteration needs to contain a set of items to be worked on during the iteration. While the time to deliver the items will have been estimated (Chapter 14) and the team velocity will have been calculated (Chapter 15), it is always possible for the estimates to be incorrect or for the team to work more slowly than predicted. As a result, it is useful to include items that have not been prioritised as ‘mandatory’ within the iteration backlog in order that there is some contingency should delays occur.

For example, if using MoSCoW prioritisation, the iteration backlog might contain several ‘must have’ items, some ‘should have’ and some ‘could have’. This set of items provides a basis for ensuring that the urgent mandatory requirements are addressed and that there is the opportunity to work on the lower priority ‘should have’ and the optional ‘could have’ features. Where items take longer than originally conceived, perhaps because greater complexity emerges during the development team’s work and delays are encountered, the lower priority requirements provide a means of ensuring that no time is wasted in the iteration and that the urgent mandatory requirements are delivered. The inclusion of different priority levels provides contingency and reduces risk. The iteration backlog is a key element in iteration planning and is considered in detail in Chapter 15.

REQUIREMENTS CATALOGUE OR SOLUTION BACKLOG?

It is important to recognise that the focus of the requirements catalogue is different to that of the backlog. For this reason, it may be helpful for an agile change project to have both documents, each providing a specific set of information as follows:

The importance of pre-project analysis, where a proposed initiative is investigated and options evaluated, was discussed in Chapter 6. This work is unlikely to benefit from the development of a solution backlog because at this stage it is not known whether a solution is required or feasible. However, it will always be important to record the business requirements, as they form the basis for understanding why a change project is needed and the key aspects to be included. There may also be some technical issues or constraints that need to be considered when evaluating the feasibility of a proposed solution. A requirements catalogue is a useful document to record these types of requirements.

The nature of some of the requirements, for example, general requirements and technical requirements, may mean that they need to be viewed separately from the functional features to be delivered. A data protection requirement, for example, may need to apply across all the features of the solution and the different elements, whether software, process or people. These requirements need to be defined so that they provide a context for the rest of the work, and techniques such as use cases or user stories do not offer an efficient way of doing this. It is preferable for the solution-wide requirements to be recorded as a distinct set. A requirements catalogue setting out any solution-wide requirements and used in conjunction with a solution backlog formed of work items to be delivered would meet several needs. This approach would:

It is useful to distinguish between the work items to be delivered during an iteration and the requirements that must be applied to the entire solution. The solution backlog is an excellent tool for recording work items to be undertaken on a change project. It provides an effective means of driving the release and iteration backlogs, and helps to ensure that prioritisation work is focused on meeting immediate needs. However, a requirements catalogue provides an extremely useful structure and format for the broader requirements that are not best defined using feature-based techniques such as use cases and user stories. Using a requirements catalogue in conjunction with the solution and related backlogs will enable a change project to ensure that work is governed effectively and conducted to address business needs.

RECORDING NON-FUNCTIONAL REQUIREMENTS

Non-functional requirements are often the most difficult requirements to define. There are several reasons for this, including:

Another issue is that some non-functional requirements only apply to a specific feature or a small area of functionality, whereas others apply much more widely. A response-time requirement may relate to just one user story – for example, the time to provide a quotation for a service – while another such non-functional requirement – for example, the time to return information following a query – may apply across the entire solution.

Some non-functional requirements, such as archiving and deletion, relate closely to legal and business policy needs and may be concerned with areas of data rather than functional requirements. Others, such as availability, may apply to every aspect of a system. Some of these purely relate to an IT system, some to a combination of manual and automated processes, while others may be completely manual. As this indicates, there are a lot of reasons why non-functional requirements require considerable analytical work if they are to be defined clearly.

Where a non-functional requirement has a very specific purpose, it may be included within the relevant user story. If we take as an example the response time requirement mentioned above, we might develop a user story as follows:

The bold section comprises the non-functional requirement relating to response time. As this is documented within a user story, it provides enough information for further discussion but does not set out the requirement in detail.

However, if there is a non-functional requirement that applies solution-wide, then documenting it within each user story would be impractical and confusing. Instead, it may be preferable to document it within a requirements catalogue section that is dedicated to non-functional requirements. A good example of this would be a security requirement where there are several different levels of security across different areas of data, one way of recording this succinctly is to use a matrix. An example setting out the access permissions and limitations for a ticket sales website is shown in Figure 13.3 below.

 

Figure 13.3 Example requirements catalogue definition of access requirements

Another possibility is to highlight non-functional requirements at an outline level but using a more visible form. For example, as shown in Figure 13.4, it can be useful to create sticky notes that provide the essence of the non-functional requirements that are particularly relevant to a current iteration. The specific details may then be recorded formally in the catalogue where they can be accessed when needed and the notes ensure that the relevant non-functional requirements are kept visible to the agile team. This approach is particularly useful for non-functional requirements that apply across the solution and could also be used for constraints related to general and technical requirements.

 

Figure 13.4 Visible non-functional requirements and constraints

Note: NFR = non-functional requirement.

Each non-functional requirement should be considered separately to identify the best recording mechanism. A general rule is that solution-wide, non-functional requirements are best documented in a catalogue, although it is advisable to couple this with the more visible approach described above. The catalogue will provide a means of describing each requirement in the most appropriate way; the access requirements example shown above is an example of one approach but others will be required for different types of non-functional requirements. A textual description of the requirement may also be useful where it applies to just one feature or user story but contains significant rules and complexity.

HIERARCHY OF REQUIREMENTS

The different types of requirement form a hierarchy that is invaluable during business analysis, particularly within an agile environment. This hierarchy is shown in Figure 13.5 below.

Some of the general requirements, as discussed earlier, may state legal regulations or policies with which the solution must comply. Some requirements are raised by stakeholders who know what they want the solution to include to achieve a business goal. These are all within the general requirements category and are at the top of the requirements hierarchy. The general requirements set the context and the high-level goals for the solution. They also provide the basis for further analysis and definition, and thereby support the elicitation and elaboration of the more detailed functional and non-functional requirements to be provided by the solution. The technical requirements have a different role in that they set constraints within which the functional and non-functional requirements must operate. Therefore, there is a hierarchical link with both general and technical requirements, each with a different focus.

 

Figure 13.5 Hierarchy of requirements

The general and technical requirements must be understood if the delivered product or system is to offer value to the organisation. Without this understanding, the customers may request features or quality characteristics that would meet local needs or support individual experiences but not address broader organisational requirements or consider the impact of such requests on timescales or costs. A recent report (Luftman et al., 2012) emphasised the importance of the alignment between the business and the IT function, and the concerns chief information officers have about the lack of such alignment. This is where business analysis can offer insights that are necessary if requests for services, features and characteristics are to be considered advisedly. One way of ensuring this is to consider the rationale for a requirement – in particular how it links to aspects such as the business strategy and CSFs for the organisation. In some situations, asking the customer why a particular requirement is needed can be vital in eliciting the real nature of the business need and ensuring that root causes of problems are addressed rather than symptoms just being masked.

Deriving detailed requirements

Where an overarching business requirement or need has been expressed, it is often possible to analyse the requirement to derive more specific solution requirements. For example, a business policy regarding customer support is likely to generate several usability and accessibility non-functional requirements; data protection regulations concerning confidentiality of personal data will give rise to non-functional requirements regarding access permissions and restrictions, deletion timescales and so on; a business process requirement regarding a new service to be offered to a customer may cause the creation of functional requirements covering aspects such as information provision, service registration and service delivery.

Understanding the hierarchy places any customer requests firmly in the business context and enables the business analyst to understand the rationale for the requests. It also provides a structure for understanding overarching business goals that may then be decomposed into lower-level goals (see Chapter 8).

Hierarchy of use cases

Business use cases, as described in Chapter 6, provide an excellent basis for setting out the overall context and scope for a change or development project. They provide a means of identifying user roles and reflecting the needs expressed by senior managers within the organisation. They can also be used to relate business events (or triggers) to a business process and to the achievement of a business goal. They provide a means of prioritising at a business need level and allow the customers to clearly show which areas of the solution are considered to have the most potential value.

Use cases can be decomposed from a business to system level where the solution is an IT system; this is reflected in Figure 13.6 below. This also provides a hierarchical structure whereby decomposed business goals and the corresponding functional requirements can be represented. Ensuring that the hierarchy and the links between the levels reflect the needs of the business is a key business analysis task.

 

Figure 13.6 Decomposed business use case into system use cases

An alternative decomposition may form a hierarchy that includes system use cases, reflecting the functionality to be provided by an IT system, plus other actors providing services or conducting work that is outside the system under development. The business use case may incorporate work that needs to be performed manually by the business staff or may require services to be provided by an external organisation (see such as a requirements Figure 13.7). A typical example is the use of online payment services from specialist organisations, such as Worldpay or PayPal.

 

Figure 13.7 Decomposed business use case showing external actor component

One of the major limitations of use cases is that they document functions to be provided by a business or IT system. So, business requirements such as complying with data protection legislation or applying organisational branding, are not well recorded using a business use case approach. Similarly, the majority of technical constraints and non-functional requirements are recorded more accurately using alternative approaches such as a requirements catalogue or matrix.

Hierarchy of user stories

Agile practitioners have long created user stories as a means of recording and defining the features required in a solution. A user story is a statement of desired software functionality told from the perspective of a user role. A user story should be of a sufficiently small size to be delivered within an iteration. Chapter 12 describes the structure and format of user stories, explaining that in themselves they do not contain enough information to deliver the finished product or solution; they form the basis for further analytical and design work.

However, user stories may be developed at different levels of granularity. Sometimes the business stakeholders identify user stories that are at an overview level, requiring the delivery of a business goal; often these user stories cannot be developed within an iteration because of their size. Such user stories are known as ‘epics’ and are typically too large and complex to estimate with any degree of accuracy. Epics need to be split into smaller user stories that can be delivered by an iteration. It is possible that some of the smaller stories within an epic may be delivered by the manual processes supported by the software rather than by the software product itself. Again, we can form a hierarchy, using the user story technique, to move from high-level business stories and goals to more detailed and specific stories with smaller goals.

User stories are used during both the analysis and the planning process for agile software development projects. They provide insights into the features to be included in a software product and provide a means of breaking down functionality to a granular level.

One of the criticisms often levelled at user stories is that they can present a fragmented picture of the solution and, when this approach is used, it is difficult to see the whole picture. One way of dealing with this issue is to combine the development of use cases and user stories such that a holistic view of the required functionality is obtained. The user roles are the key sources for both use cases and the user stories so these techniques work well together to identify and define functionality. Two possible approaches to avoiding fragmentation are:

Whichever is the case, it is useful to recognise that the higher-level, more complex user stories are typically identified first and then decomposed to reveal specific user stories focused on achieving more detailed sub-goals. The user stories are recorded in the solution backlog and prioritised to indicate which features are the most important. The effort to develop each user story is estimated. A set of estimated, prioritised user stories can then be selected to form the basis for the work of an iteration.

Business analysts may be needed to explore the user stories, particularly if there are more detailed aspects such as tacit knowledge, data, business rules or interactions to be uncovered. These more detailed areas are not recorded in the backlog but form the models associated with the original user story.

CONCLUSION

There are several different approaches to recording requirements, each of which may be helpful according to the particular circumstances. This chapter has looked at some of the standards that may be adopted to record and manage the features to be included in a solution.

Business analysts should have expertise in applying a toolkit of approaches to elicit, analyse and document business needs at different levels and across a range of aspects. For this reason, they are well placed to offer support to the project, helping to record, prioritise and investigate the solution requirements, features and goals. Identifying the most relevant and useful approach to adopt when recording these items is a key element of business analysis. It is particularly important when working in an agile development environment, as following documentation standards blindly or recording unnecessary levels of detail at an early stage can result in wasted efforts that could have been expended elsewhere to deliver greater benefit.

REFERENCE

Luftman, J., Zadeh, H.S., Derksen, B., Santana, M., Rigoni, E.H. and Huang, Z. (2012) Key information technology and management issues 2011–2012: an international study. Journal of Information Technology, 27 (3): 198–212.

FURTHER READING

Cockburn, A. (2000) Writing effective use cases: the Agile software development series. Boston, MA: Addison Wesley.

Cohn, M. (2004) User Stories applied: for Agile software development. Boston, MA: Addison Wesley.

Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.