2      BUSINESS REQUIREMENTS

Now that we understand the context and purpose of UAT the next stage is to understand the business requirements. This chapter explains what requirements are, how requirements are written and how the business requirements relate to UAT. It will also become clear why requirements may be out of sync with the real business requirements by the time UAT takes place and how this limitation can be overcome.

BUSINESS REQUIREMENTS

In Chapter 1 the fit between an IS and its business users was referred to as being like the fit of a garment that is ‘made to measure’. Using the same analogy a requirement identifies something that the customer wants to specify about the item of clothing about to be made for them. Similarly, a business requirement is something a business wants to specify about the IS it is about to have built or is about to acquire. In other words a requirement is simply something that we need and in the context of an IS, a requirement is something we need from the system. The better the desired outcomes and the detail of what the system ought to do is understood, the better the chance of delivering what is needed. Requirements describe what a system ought to do, what will be built and what will be tested during UAT.

Having captured the needs of the organisation the project team will document them in a requirements document using clear and simple language and using the terminology of the user. These requirements, if too general to be of use to developers, can then be translated into a more technical version using a structure aimed at helping the development team to understand and build the system. The resulting document is known as a requirements specification (RS) and the detailed needs of the business contained in it are the requirements.

BUSINESS INTENT AND USER EXPECTATIONS

We established that requirements are gathered and documented in a business requirements document, a set of statements that describes all of what a user community wants from the IS. The requirements as a whole should reflect the overall objectives and expectations of the business. These overall objectives and expectations, although they are often forgotten, should also be documented.

Every IS is created for a purpose: to achieve some business benefit such as improved productivity for staff or reduced costs of operation. The purpose of the system is usually called its ‘business intent’. Business intent is important because it identifies what the business is expecting to be able to achieve when it has the system installed and operating.

Arising from the business intent the sponsor, managers and end-users will have a perception about what the system should do and how it should behave. Users of systems already in place will also have expectations based on their perception of the way they currently work and the way they are expecting to work with the system. Expectations may not be exactly aligned with business intent but they are an important element of perceived success, so they should be captured as an input to UAT.

A key driver of success in IS implementation is the transparency of business intent and user expectations so that all stakeholders, including the developers, have a common understanding of what is required and what is expected in an IS solution. The absence of effective transparency is a key risk factor because the parties may be operating from different assumptions, and UAT is the final opportunity to identify and resolve any misunderstandings that may have arisen during development. If the business requirements match the business intent and the system meets the business requirements, the business intent will have been achieved.

Example 2.3 – Business intent

•  The system will enable the business to manage 250 customer accounts simultaneously.

•  The system will enhance throughput of widgets by 10 per cent.

•  The system will enable the business to offer five new services.

•  The system will enable the business to deliver customer orders within 48 hours of order.

The business intent should be measurable and immediate. Once the system is installed it will be possible to determine if the business intent has been achieved, so it is also feasible to test for achievement of the business intent at UAT. A more strategic long-term objective, such as reducing staff numbers for example, cannot be tested at UAT. For this reason it is preferable to base the achievement of longer-term objectives on improvements that can be seen and verified immediately.

ACCEPTANCE CRITERIA

Before we look in more detail at the requirements and the different requirement types, we should examine the acceptance criteria.

The business requirements tell us what the system must do for the business so we will base our tests on them. Acceptance criteria, on the other hand, tell us how we will know that the system is fit for release to its users. In other words acceptance criteria are our way of determining when we have done enough testing.

Example: at least 90 per cent of all business requirements must be tested.

This acceptance criterion prevents a scenario in which only a small sample of requirements end up being tested. Acceptance criteria can be quality-related as well as system-related. For example we would not want a system released if all requirements had been tested and all the tests had failed. We can guard against this eventuality by imposing quality-related criteria.

Example: there must be no critical defects outstanding at release.

Acceptance criteria are the conditions that must be satisfied before a system can be accepted by the users or stakeholders. Accurately defining the acceptance criteria is one of the most important elements of a successful development project and clear acceptance criteria are critical to the success of testing. Inaccurate or incomplete acceptance criteria can lead to low customer satisfaction levels, missed deadlines and increased development costs.

The fact that all documented requirements should be met would be an implicit acceptance criterion, although it could also be stated explicitly. Other criteria would extend this to define the status of the system when it is offered for release. Examples might be:

•  All requirements shall be tested before release.

•  There shall be no critical defects and not more than two high-priority defects outstanding on completion of acceptance.

•  There shall be no unallocated incident reports outstanding.

These three criteria should ensure that what is released is complete and in a stable state, which is clearly important for the user population.

Acceptance criteria have another useful purpose. If, at the scheduled release date, the acceptance criteria have not all been met, they can be used to provide a measure of outstanding work and the possible delay if the system is held until all criteria are met.

For example if a system has one critical defect and four high-priority defects outstanding, we can discover relatively easily how long it will take to clear the defects and retest to ensure the fixes are correct. This provides a measure of possible delay. We could also consider whether the effects of any of the outstanding defects could be mitigated by some kind of ‘workaround’. Acceptance criteria set up a dialogue between UAT, developers, users and sponsor through which a release date acceptable to all can be negotiated.

THE REQUIREMENT TYPES

So far we have identified that the RS is a document, usually written by a business analyst or a developer, which defines the business requirements in a form that developers can understand and respond to. However, the requirements are not homogenous and we can identify different types of requirements: functional requirements, informational requirements, behavioural requirements and environmental requirements. The RS should ideally contain all the different types of business requirements as well as expressing business intent, capturing user expectations and defining acceptance criteria.

In practice a RS may not contain all of the information we need and the translation from business-speak to developer-speak that we mentioned earlier may have ‘blurred’ some aspects of the business requirements. Worst of all, the RS may have to be written and approved before development can begin so that it represents a snapshot of what the business requirements were believed to be at the beginning of development.

We will, in all probability, need to supplement the RS before we can plan, design and run effective UAT and we will see how we do that in Chapter 6. For now we will work on the basis that whatever documentation we have is an adequate expression of business requirements.

PRIORITISING BUSINESS REQUIREMENTS

Neither time nor resources are unlimited for UAT so tests probably have to be prioritised in some way that balances the expectations of each stakeholder group. Prioritisation also ensures that if time runs out, everyone can feel reassured that the most important (highest priority) aspects of the system have been tested.

Sponsors will naturally be most concerned about the business intent so a way to express the intent is needed, and business criticality is one way to determine which aspects should be tested first. Similarly users and managers will have concerns about how the system operates so their concerns will be encapsulated in the idea of usability.

Business criticality

Business criticality is a measure of how important any individual requirement is to the success of the business or to the achievement of the business intent. We could define any number of levels from absolutely critical to not at all critical, but what is usually done is to define just two – critical and non-critical. Within these two broad categories priorities are then attached to each individual requirement (or possibly to groups of related requirements) to enable the organisation to prioritise development and plan accordingly. For UAT we can use the same measures of criticality and priority to manage the UAT priorities or, if priorities have not already been assigned to requirements, we can consult the sponsor to determine the criticality for testing.

Usability

Usability has a technical meaning that gives rise to a specific type of testing known as usability testing. For UAT we have neither the expertise nor the time or resources to do usability testing in a rigorous way, but we do have a set of expectations that we can use to determine some simple parameters for testing. For example if the sponsor has an expectation that the system will be able to handle 30 specific transactions per hour then managers will have an expectation that the throughput of a single terminal multiplied by the number of terminals will at least equal the required throughput of transactions, while the end-users will want to satisfy themselves that the user interface at any single terminal will enable them to handle the expected number of transactions overall.

For each requirement or group of requirements the business criticality can be used to generate a priority for testing and the usability criteria for those requirements acquire the same level of prioritisation.

Business process

The definition of UAT included testing the system according to ‘user needs’ and ‘business processes’. We will need at least some of our tests to exercise business processes so this will be a third focus for our prioritisation of requirements for testing; we will group together aspects of the system related to specific business processes and test them together so that we can determine whether the system correctly implements the business process.

THE RELATIONSHIP BETWEEN BUSINESS REQUIREMENTS AND UAT

The RS is the document we usually see as the point of contact between users, developers and testers. It is intended to express to developers what the users want so they can build the system, and simultaneously to express to the UA testers what the users want so they can test the system independently of the developers. The word ‘independent’ is very important here; it is the key characteristic of UAT.

UAT is an expression of the RS (as interpreted by UA testers); the system itself is an expression of the RS (as interpreted by the developers). Comparing these two expressions by running the UA tests is the only way we can determine whether the outcome of development matches what the users said they wanted. So it is absolutely vital that UA testers work independently of the developers in designing their tests and it is equally vital that they work from an expression of the requirements that has not already been interpreted by the developers; otherwise UAT would simply reflect the developers’ interpretation.

We have shown previously that, although it should be the embodiment of what the business wants and needs, the RS may be out of date, incomplete or inappropriate because:

•  The needs of the business were not documented in detail (or at all).

•  The needs of the business changed during the development project and the RS has not been kept up to date.

•  The documentation was deliberately written only in outline at the outset and was then developed iteratively and incrementally.

These situations are all likely to lead to a state of affairs at the end of development in which the delivered system is not aligned with (current) user expectations. In addition to the fact that the RS may not be completely accurate, further mistakes may have occurred down the line. The problem that sponsors, managers, end-users and developers have in describing what an IS must do is that the sponsors understand the business background but (usually) not the technology; users and managers understand what the system is meant to do but (usually) not how it will work; while the developers understand the technology but (usually) not the business background. A middle ground is hard to find because the four stakeholder groups use different ways to communicate and have different views of the world. What is usually done is to try to define the business need in terms the users understand and then ‘translate’ it into ‘technology speak’.

This process can cause problems for two very important reasons:

•  Translations are never simple or completely accurate, so the translation process introduces errors.

•  Both groups have a set of information that, as far as they are concerned, ‘everybody knows’. These assumptions are seldom stated in requirements because the author’s mindset does not recognise any gap in the information. Meanwhile readers take what is written literally and try to deliver it according to their own assumptions. This is a major source of serious requirements gaps.

So an RS is likely to be a flawed expression of business requirements, especially if it is drafted and approved at the start of the project. In addition:

•  Requirements defined at the beginning of a project may contain errors and/or omissions that need to be corrected.

•  Users may gain new insights during development that lead to requirements changes.

•  The business environment may change in a way that forces requirements to change (for example in a system related to taxation there may be revisions to taxation law).

We will therefore need to assess the RS and, if necessary, update the requirements as expressed in the RS at the end of the project and document these as a basis for testing.

THE RELATIONSHIP BETWEEN DEVELOPMENT AND UAT

There are many ways to develop software but most fall into three broad categories: sequential development, iterative development and component-based development.

Sequential development

Sequential development uses a sequence of development stages that typically follow a V shape as shown in Figure 2.1. Discovering and documenting initial requirements is the first stage in this process and UAT is the final stage. The approach breaks a system down into manageable chunks and functionality is not normally delivered until the end of the project.

Figure 2.1 A sequential development life cycle

Notice that the test levels relate to different stages of design in which the requirements are analysed and then broken down into smaller and smaller building blocks. The test levels then test the outcomes of each of these design stages. UAT is the final test level that tests the completed system against the requirements.

Iterative development

In an iterative approach (such as agile development) the design and testing takes place during short development ‘sprints’ so that system functionality becomes available incrementally at the end of each sprint (Figure 2.2). In this case requirements are implemented incrementally according to a plan, but not all requirements are documented initially. UAT will be required before roll-out to confirm that the system is acceptable, but there will be no requirements documentation to form a test basis.

Figure 2.2 An iterative development life cycle

Component-based development

Other common ways to develop systems build on one or other of these fundamental models. For example a system can be constructed from commercially available components integrated into an architecture that meets the business requirements. In a component-based system architecture the component ‘building blocks’ are likely to be well defined but the integration will involve greater risk. UAT should encounter relatively few problems with the way the system functions but problems can occur, for example where integration of components does not deliver exactly what was required. A related approach, using COTS software, acquires most of the functionality in a collection of existing modules; development involves configuring the modules to meet the business requirements. In this case much of the focus of UAT will need to be on whether the solution is a good fit with business intent.

SCOPE OF UAT

The scope of UAT is defined in the UAT plan and is of vital importance to its success. It defines the extent of UAT: what will and what will not be tested. Clearly the requirements will be tested but the scope explains the extent of the deliverables and the boundaries, including those things that are out of scope. We saw earlier that within this parameter we have to ensure that the most critical requirements are tested first according to the perspectives of the most important interested parties. But are there any additional things we should test or definitely should not test?

What we must test

Firstly one thing that is not negotiable is the testing of contractual requirements. If the system is being delivered in fulfilment of a contract, then we must carry out contract acceptance testing to ensure that the delivered system meets all the requirements stated in the contract. Even in this case, though, there are likely to have been variations, some documented and some not, that will need to be taken into account.

Secondly we have to aim to test the business intent and user expectations by prioritising requirements and usability according to the business criticality of each requirement. This must include anything explicitly mentioned as a deliverable in a contract and anything explicitly defined in the RS.

Thirdly we need to ensure that we test every business process from end to end. Business processes have not been tested prior to, and must form the framework for, UAT. Any functional requirements should be tested as part of the known existing or future processes as requirements that do not relate to business processes may not be relevant in the new system.

Fourthly we must test any defect fixes that are outstanding and any fixes for defects that we find.

Finally we must carry out a regression test for every change that occurs. Regression testing checks whether the defect has been fixed and confirms that the fix has not caused any other problems.

What we will not test

With the limitations of time and resources we have already mentioned, it would clearly be impossible to test everything about the IS, but then many aspects will already have been tested. Unit testing (testing the code), integration testing (testing whether parts of the code or system work together) and system testing (testing whether each part of the system functions correctly) have already been carried out, and repeating any of these tests is outside the scope of UAT.

So UAT will not test anything that has already been tested in one of the development testing phases (provided we have evidence of the tests) and, in particular, it will not set out to test all of the functions of the software.

For reasons stated earlier we will not attempt to test usability in detail; nor will we attempt to test performance, except that we will embed some usability and basic performance measurements in business process testing.

BUILDING A TEST BASIS FOR UAT

The life cycle of an IS begins with identifying and documenting business requirements, which then become the basis for development. In theory, then, we can use the requirements documentation as a basis for our UAT. In reality, however, this is not always the case, so we need a foolproof way of defining a test basis for UAT that does not rely on a complete set of initial requirements. The key sentence in the definition of a test basis (see box) is the second one: ‘The documentation on which the test cases are based.’ We need a test basis for UAT as a set of documents and what we have at present is an RS. In some situations we will have to test strictly against the original requirements; for example if a contract for development was based on them. In most cases we need to extend the information in the RS.

Evaluating/enhancing the RS

The requirements as a whole and each individual requirement need to be checked to ensure that they are of the required quality. If stakeholders are unfamiliar with how business requirements are formulated they may make their requirements too:

•  high level;

•  ambiguous;

•  focused on the solution instead of the business need;

•  general and not focused enough on specific user groups;

•  all-encompassing, lumping together multiple requirements.

Requirements are checked and updated by reviewing them as a team of interested parties and stakeholders. Members of the team may also individually review the document with a checklist (containing the characteristics of good requirements for example) to note any comments and questions before a walk-through takes place. Review techniques will be explained in more detail in Chapter 3.

If a UAT team works from the requirements as originally documented, the UAT exercise is likely to hit all sorts of problems. Our review of the RS may discover some of the problems, but it cannot solve them and we will need to be sure that we test thoroughly in areas where we believe the requirements were flawed. If we find requirements gaps we can still go back to the users to supplement the RS by revisiting business intent, user expectations and business processes. With these three sources brought up to date we should be able to form a test basis.

Our next step is to look at these additional sources to find a way of enhancing what we have in the RS.

Capturing the business intent

If the business intent is not already documented, has not been documented well or has changed, the first step will be to discuss and document the business intent with the stakeholders. The business intent represents the overall goal of introducing the IS and is a great first step in creating the test basis because it gives UAT a very clear focus on what is needed. The business intent, like the requirements, must be clear, unambiguous and measurable.

Capturing user expectations

We can capture user expectations by talking to users. Our conversations can be helped and supported, though, by a simple technique known as ‘user stories’. We can ask users to write down, or help us to write down, user stories that encapsulate their expectations.

User stories

A user story is a very brief description of what the system does for its users to help them perform their work more easily. User stories are used in agile development ‘to facilitate the discussion and support planning’ (Adzic, 2009: 160). They are a valuable tool for us because they avoid any details of specific requirements or of how they might be implemented. They simply provide a very brief and simple expression of user expectations.

A typical user story is made up of one or two sentences in the everyday language of the end-user that covers what a user needs to do as part of their job function. One common format is to use the formula ‘as a ....... I want ....... so that .......’. This gives a clear link to expected benefits without asking users to articulate any details of specific requirements and is ideal for our purposes.

Example 2.4

As a team member I want to be able to complete a draft contract so that it can be processed.

As a manager, I want to be able to approve a contract created by my team.

The ‘three Cs of user stories’ (http://www.xprogramming.com/xpmag/expCardConversationConfirmation.htm) provide a good practical basis for capturing and exploring user expectations.

Card

User stories can be written on small index cards; small enough to capture the key idea and not large enough for a complete requirement. The cards can then be used as tokens for discussion.

Conversation
The conversations related to user stories can explore the relationships between stories and, if necessary, add detail for clarification.

Confirmation
Each user story must be verifiable so that we have a way of knowing whether it has been correctly implemented or not.

An exercise in collecting, documenting and discussing user stories can add not only a clear idea of what user expectations are, but also a means of identifying the results we would expect to get from a test based on each user story. This is exactly what we need.

Capturing business processes

We will need to review the business processes and check that they interface correctly with the requirements, for instance that the requirements contain all the functions and accept inputs as defined by the business processes. If necessary we may have to supplement them. We will describe the review technique in greater detail in Chapter 3.

Where business processes interface with the computer we can use the concept of use cases to capture what the software should do for each user activity and then compare that with the RS.

Use cases

The definition (see box) describes precisely what we are looking for. It involves a dialogue between an actor and the system that makes up a sequence of transactions with a tangible result. An actor is a representative of some role (such as an end-user who is making a purchase or an end-user who is completing an order); the transactions are the actions accomplished by the system for the actor. So here we have a description of how a user role would interact with the system to achieve some goal (such as placing an order).

As well as actors, use cases are normally associated with scenarios, where a scenario is a sequence of steps representing one specific action. In our case we can build a scenario for the ‘normal’ process, meaning the scenario in which everything works correctly and the process completes successfully. We can then add supplementary scenarios to explore the ‘error’ cases, for example where the process diverges from the ‘normal’ case in some way.

Use cases can be expressed in simple diagrammatic form or as a sequence of numbered steps. For our purposes the latter is probably the better option so that users can work with us as we build out the use cases that represent the business processes and their interactions with the system.

Table 2.4 Use case

Example 2.5

In this use case the actor role is the travel agent (an end-user of the system who uses it to sell holidays). The alternative scenario explores what happens when no suitable cabins are available.

This is a simple use case but it is easy to identify business process steps not involving system interaction (step 1) and system interactions (steps 2–6). The interactions can be described in more or less detail, as can the parts of the business process not involving the system. Use cases are potentially much more detailed than user stories and are normally aimed at providing developers with complete requirements.

If use cases have been used in capturing the initial requirements we gain the benefits for very little additional effort. If not, use cases provide one of the simplest and quickest ways to capture key information.

We will see how we can deploy user stories and use cases in setting up a UA test basis in Chapter 6.

What have you learned?

Test your knowledge of Chapter 2 by answering the following questions. The correct answers can be found in Appendix B.

1. How could you best define the business intent?

A.  The main reason for and benefit of the new system

B.  The reason for carrying out UAT

C.  The expectations users have of how the system will work

D.  The purpose of the business

2. What are business requirements?

A.  A strategy for UAT

B.  The test basis

C.  A set of statements that describe what the system ought to do

D.  Both (b) and (c) are true

3. What is a limitation of requirements?

A.  No requirements may be recorded

B.  Things have changed since the requirements were written

C.  The requirements may not be recorded in enough detail

D.  All of the above are true

4. Which of the following is a characteristic of an unsuitable requirement?

A.  Too much detail

B.  Too high level

C.  Not technical enough

D.  Focused on the business need not the solution

Some questions to consider (our responses are in Appendix B)

1.  You are a stakeholder new to the project and are asked to read the RS to get an idea of what the project is about, but you do not understand some, most or all of the requirements. What would you do?

2.  What is the difference between an RS and a UA test basis?