Blog - Business analysis training courses, e-training and consulting

Requirements analysis and modelling

Requirements analysis

As requirements are discovered (elicited) and captured, they should periodically be analysed; they can be analysed for completeness, correctness, priority, release date, ambiguity, clarity, testability, achievability, cost, risk, scope, cultural feasibility, etc. This is true whether the requirements are captured as user stories, use cases, business tasks or any other format.

The requirements analysis process involves checking backwards with the requirements owners (e.g. product owner(s)) and forwards with the stakeholders who will use the requirements in some way, e.g. to design, build. test, release or administrate the required system.

In checking back (requirements validation) with the owners of the requirements, we are trying to ensure that the real business needs have correctly identified and defined. Consider the goals of the project as well as the overall goals of the organisation, the business case, the priorities and the scope for the project; does the requirement respect these? Have the goals or the scope changed, perhaps with a change of sponsor for example? Do the requirements seem to be related to the original problem? Do we remember what that problem was? Have we identified and involved all of people and groups affected by the requirements?

In these reviews with business stakeholders, ensure that they really do understand the requirements as written. Is this what they wanted? The big question to ask is, ‘How will the requirements, as written, contribute to the solution of the original problem?’ This is the rationale for the requirement; it can sometimes be very difficult to get the stakeholders to clearly specify a rationale. If there is no rationale, the requirement needs to be dropped.

In reviewing the requirements with the people who will build or otherwise acquire as system that satisfies the requirements, we need to ensure that a system as represented by the requested requirements can be built and tested within the defined constraints. In the context of testing, and of development, we need to ensure that there are clear and unambiguous acceptance criteria. The obvious way of doing this is to have the requirements reviewed by the people who will be doing the building and testing; the architects, designers, programmers, testers and release managers.

A well constructed requirement should normally permit multiple solutions. Is this true of the requirements at hand or are they actually solution statements masquerading as requirements? If they are solutions, is this ok? Usually it is not.

That said, we also need to ensure that the required product can be developed within the constraints imposed by the business. Realistic costs can only be determined in the context of the design options, or potential architectures.

Assessment of requirements must therefore involve people with sufficient technical skills and experience to understand the likely implementation costs. If the organisation cannot afford the solution, or cannot justify that expense in terms of benefits, it is not worth continuing with the development.

If what is being requested is not feasible for any reason, e.g. technical complexity or cost, the designers and architects may be able to come to the rescue with an application of the 80:20 rule; e.g. make some changes to the requirements to be able to get most of what you want with less risk and cost.

Requirements reviews, as described here, should be done as early as possible. The earlier in the life cycle the problems are discovered, the quicker and easier it will be to resolve them. This increases the chances of achieving a workable solution first time. Obviously, just because it’s workable does not mean that it really will solve the business problem or will realise the opportunity; in the end, we just have to get it out there and see. This a justification for agile style developments with ‘minimum viable products’ and ‘failing fast’.

Analysis with Models

There are risks in relying purely on text to define requirements. Ambiguity is a problem. It can be difficult to assess completeness. One solution, or partial solution, to do these problems is to use models.

There are mixed opinions about the value of models, particularly formal models. One option is to use informal models, sometimes referred to as napkin models. These are easier for business stakeholders to create and can be less intimidating. Formal models however have more rigour; they are essential when we are intending to automatically generate applications and databases from models. Popular forms for formal models include UML and BPMN.

For Complex systems (with the capital ‘C’), there are other considerations in terms of value of models, but such highly specialist considerations are beyond the scope of this article.

Analysis and Prototyping

Another way of mitigating risks inherent in requirements defined as text is prototyping. Prototyping is popular but there are consequent risks such as the popularly quoted management of user expectations. Another risk is that we may suddenly find that we are no longer dealing with requirements but with solutions; as stated above, a well formed requirement should allow for multiple solutions.

When we are eliciting requirements, the prototype should be as minimalist as possible; the prototype should be used to encourage discussion about the real need.

When we are validating requirements, prior to purchasing a solution or starting system development, the prototype should be detailed enough to show what the system will look like. This gives stakeholders a chance to say, “Now that I’ve seen it, I realise that it’s not what I want.

Managing Expectations

Our analysis, including reviews, modelling and prototyping, should clarify everyone’s ideas and should give us confidence that we are on track to create what is really needed to solve the business problem or realise the business opportunity. Such clarity facilitates estimating the workload ahead and helps to set expectations and share a vision. All of this will be good news to the project manager and senior management.

Requirements discovery is child’s play

Chinese Whispers in requirements discovery

The child’s game, referred to in English as Chinese Whispers, is one in which children, typically seated in a circle, receive a whispered message from the person on one side and whisper it to the person on their other side. The last person in the circle has to say out loud what they they heard.

To the delight of the children, this usually has nothing to do with the original message. Unfortunately the process of requirements discovery also displays some of the characteristics of the child’s game. The more links in chain, the more likely that there is miscommunication.

Business analyst – Problem or Solution?

Communication problems in requirements engineering — Links in requirements discovery

Perhaps the easiest way of solving this problem is for the person with the requirements to talk directly to the person who will provide a solution. This minimises the number of people in the chain and consequently the possibilities for misunderstanding. Some ‘agile’ projects work this way, often with great success. Sometimes with not such great success.

The job of the business analyst is to listen to the person with the requirements and to pass on these requirements to the people who will participate and cooperate in the provision of a solution. So what value add does the business analyst offer?

If the business analyst is simply acting as a relay, the answer to this question is, ‘very little – if anything’. In fact, if the person with the need is capable of clearly defining the problem to be solved and the requirements that any solution must satisfy, the business analyst would be redundant.

What can the business analyst bring to the party?

The value of the business analyst rests on their capability to deal with issues such as the following:

the problem is often not well understood or well defined
the solution attacks a symptom rather than an underlying problem
the requirements are not well expressed
there are usually many people with specific, perhaps personal, goals and requirements
the budget may not be sufficient to satisfy all the requirements
requirements, and even goals, may be mutually conflicting
suggested solutions may not be culturally feasible
the implemented requirement improves one bit of a process but worsens the overall outcome
the requirement satisfies a group of stakeholders, but not all of them
continuous reinvention of the wheel

and so on.

To be of value, the business analyst needs to do much more than simply pass on a message.

Business analysts analyse business problems

The business analyst (BA) must get to the root of a problem or the essence of an opportunity. They must frame requirements without unilaterally imposing an arbitrary solution. They usually need to assist concerned parties in creating a common understanding of the business problem or opportunity that is being targeted by the project. They often need to negotiate with with the business and with IT in order to identify an approach to a solution that recognises constraints, priorities, benefits and risks.

Simplify your business rules with decision tables

Is this you?

Have you ever struggled to capture business rules or requirements that involve multiple conditions?

Picture of a man during the reading time of a BCS exam — I’m getting a headache

If yes, you’re not alone. I’ve met many business analysts struggling to specify business rules and multiple conditions using techniques such as user stories or traditional requirements formats. And they end up in a tangle.

When I demonstrate decision tables, it’s like an epiphany. I’ve even had analysts ask if they’re allowed to use the technique – “Shouldn’t we be using user stories?”

Decision tables are a great technique for business analysts, business architects, developers, business rules specialists and testers alike. They are equally applicable to agile and to traditional teams. And the good news is, they’re simple to learn.

There are two forms of decision table. In this article we’ll look at the most basic form, known as ‘limited entry’.

We start with the conditions.

Conditions

Start with an IF

Conditions are the ‘IFs’ and possibly the ‘WHENs’. E.g.,

IF order value greater than £500.00
IF client is loyalty scheme member

However, in decision tables we do not include the IF word. For example, we could simply write:

Order value greater than £500.00
Client is loyalty scheme member

Imagine a question mark at the end of each of the above statements, e.g. Order value greater than £500.00?

This is either TRUE or FALSE. Some decision table users refer to YES and NO. The more mathematically minded might even use the numbers ‘1’ and ‘0’ instead of true or false, yes or no.

Procedure

Brainstorm or workshop all the conditions that you can think of. One of the great things with decision tables is that you can write them down in any order.

Decision tables can handle any number of conditions but to explain the technique we’ll start with a very simple situation with only two conditions.

The situation is a hotel check-in. Possible conditions might be:

Does the client have a booking?
Is there a room available?

The column of conditions is known as the ‘condition stub’

True or false?

Part of decision table showing simple conditions — Simple conditions

Each condition is either true or false, e.g. the guest either has a booking or they don’t. A typical beginner’s mistake is to add additional conditions such as, ‘Guest does not have a booking’; this is unnecessary.

In the diagram labelled ‘Simple Conditions’, we have represented ‘True’ with a ‘Y’ for YES. We have represented ‘False’ with an ‘N’ for ‘No’.

Combinations of conditions – Rules

You can see that with two conditions there are 4 possible combinations of true and false. A great thing about decision tables is that we can be absolutely certain that we have identified all combinations of conditions; we have missed nothing.

If there are 3 conditions, there are 8 combinations of true and false.

For 4 conditions there are 16 combinations of true and false.

You can probably see that the number of combinations rises steeply with each extra condition. But however large the number combinations becomes, we can be absolutely certain that we have identified all of them; we will have missed nothing. That should be reassuring to business analysts, solutions architects, programmers, testers, project managers and business stakeholders.

The good news is that there are a couple of techniques we can apply to simplify complex tables. These are known as:

Indifference
Else

We shall examine these later.

We have labelled each combination of conditions as a ‘Rule’; i.e. Rule 1, Rule 2, Rule 3 and Rule 4. In the language of decision tables, these are collectively known as the ‘condition entries’.

Actions

Having identified the conditions, we can identify actions. Note that we could have identified the actions before we identified each of the combinations of conditions, i.e. the rules. Decision tables allow us great flexibility in the order with which we do things.

In our example, we have identified four actions:

Check in guest
Create booking
Find room in another hotel
Recompense guest

This set is referred to as the ‘action stub’.

In our decision table, we have listed the actions below the conditions. We have separated conditions and actions with a thick blue line.

We could have listed the actions in any order we like. There is no limit to the number of actions we can identify.

Associating Rules and Actions

The combination of conditions, as defined in the rules, with the actions is a way of writing business rules.

For each combination of conditions, i.e. for each rule, we examine each action in turn.

For each rule, we determine whether or not an action is applicable. We do this by putting an X where it is applicable and a dash (–) where it’s not.

If the action is applicable for a particular rule, put an ‘X’ in the cell for that action in the column for that rule. E.g.

If a guest has a booking
AND
If a room is available
THEN
Check in guest.

In the diagram, ‘Condition and Action Stubs + Condition Entries‘, notice the ‘X’ in:

Row: ‘Check in guest’
Column: Rule 1

If the action is not applicable, either:

Put a dash, ‘-‘, in the cell
OR
Leave cell empty

For example, notice in the diagram that there is a ‘-‘ in the column, ‘Rule 1’, for each of the the following action rows,

Create booking
Find room in another hotel
Recompense guest

I.E., none of these 3 actions is applicable if the guest has a booking and a room is available.

More complex decision tables

The example, ‘Incomplete decision table with 3 conditions’, shows all the combinations of true and false, or yes and no, when there are three conditions.

We can see that in this case there 8 possible combinations of true and false (yes and no), denoted by rules 1 – 8.

The decision table format gives us confidence that there are no more possibilities. We have not missed anything.

We can similarly handle 4 or more conditions. Each time we will know that we have identified all possible combinations.

However, it’s always a good idea to try to simplify things a bit.

Simplifying complex decision tables

If there are many conditions, a decision table can become very large. Fortunately we can usually manage to simplify such tables by using ‘indifference’ and ‘else’

Simplifying by using the ‘Indifference’ symbol

The indifference symbol is a ‘-‘ (i.e. a dash or a hyphen).

The example shown in the adjacent diagram, ‘Partial decision table showing indifference’, is based on a scenario such as purchasing a train ticket online.

Before the payment can be processed, it is often necessary to accept the terms and conditions (T&Cs). This is usually done by clicking in a checkbox.

If the user had not indicated acceptance of the T&Cs, the payment cannot be processed. Typically the system displays a message telling the user that they must accept.

In our diagram, there is an ‘N’ in Rule 1 of the ‘Terms and conditions agreed’ row.

The ‘N’ tells us that the T&Cs have not been accepted. In that case, it does not matter what is in the other conditions for Rule 1. The resultant action will always be the same. If T&Cs have not been agree, we are not going any further.

The action is ‘Display “T&Cs must be agreed” ‘. In the diagram there is an X in the row for that action.

There are likely to be similar conditions, e.g.

Card payment details incorrect
Post code missing
etc.

Items such as the above are mandatory for payment processing to proceed.

Simplifying with Else

Partial decision table showing use of ELSE

Having dealt with cases such as mandatory items being completed, we often find that all other rules result in the same action or actions. This allows us to replace all of those rules (columns) with a single column labelled ELSE. See the adjacent diagram, ‘Partial decision table showing use of ELSE’.

Notice that all the cells in the ELSE column are blank. ELSE represents all situations other than the three covered by rules 1, 2 and 3.

The table shows us that for all situations other than for rules 1, 2 and 3, the resultant actions are:

Action 2
Action 3

Summary

Not every requirement is best specified with a user story or a use case or with traditional formats such as, “The user shall …..”.

Decision tables are a useful technique for business analysts when specifying applications and systems that involve multiple conditions and business rules.

They are also useful for programming, design, testing and management.

Try adding them to your toolbox of business analysis techniques.

Simple Steps for Better Business Process Design

Better business process design and modelling

In this article, we look at some simple steps to improve the design of your business processes and your business process modelling.

A Process Hierarchy

Business process hierarchy — Example of a simple business process hierarchy

The diagram shows a hierarchy of activities. Each is named in the verb noun format, and is singular, i.e. ‘Fulfil Order’, not ‘Fulfil Orders‘

It is common to refer to the activity at the top of such a hierarchy as a ‘Process’ and the activities at the bottom as ‘Tasks’. This suggestion for terminology was made by Sharpe and McDermott in their book, “Workflow Modelling”.

The diagram is often referred to as a ‘process hierarchy’. It allows us to analyse and design the structure of a process without refering to data, business rules, or sequencing.

All models are simplifications of reality. One key to successful modelling is to ignore anything that is irrelevant to the objectives of your model. Here, we are trying to understand the structure of the business process and its tasks, so we focus on those.

Designing the ‘Process’ Hierarchy

The top level activity in our diagram is ‘Fulfil order’.

It has low level activities:

Take Order
Prepare Order
Deliver Order

Each of these activities is likely to be performed by separate organisation units.

Some process modellers might refer to activities at this level as ‘sub-processes’, depending perhaps on the size of the activity.

The modeller must ensure that ‘Take Order’, ‘Prepare Order’ and ‘Deliver Order’ really do cover everything that is assumed to be in ‘Fulfil Order’.

The modeller might realise at this stage that ‘Fulfil Order’ implies something more or something less than than the three lower level activities identified above.

The modeller might then take corrective actions such as adding and removing activities, or simply make name changes so that the names at both of the two levels adequately describe what is going on.

This work is likely to be iterative, working alternately, top down and bottom up.

It is worth taking the effort to get things ‘right’ at this stage because it can help to ensure that we are designing the optimal structure for the process.

In our model, the activities, ‘Take Order’ and ‘Prepare Order’ have been expanded to a third level of detail. This approach of working top down to the detail is sometimes described as ‘process decomposition’.

The modeller must now ensure that ‘Record Order’ and ‘Allocate Order’ completely describe ‘Take Order’.

Similarly, that ‘Pick Order’ and ‘Pack Order’, completely describe ‘Prepare Order’.

Tasks – The Bottom of the Hierarchy

Referring to our earlier suggestion that the activities at the bottom of a hierarchy are referred to as ‘tasks’, we can see that there are five tasks, each labelled with the letter T. Note that 4 of the tasks are at the third level of the hierarchy, whereas one of them, ‘Deliver Order’, is at the second level. In practice, ‘Deliver Order’ will probably be decomposed into smaller activities. A useful guideline for what constitutes a task is, ‘Work done by one person, at one place, at one time’; ‘one person’ might be a group of people effectively acting as one.

There is no fixed rule about how many levels there should be in a process hierarchy; Usually, three or four will be sufficient to understand an existing system or to propose a new one. It is also likely that each leg of the hierarchy will consist of a different number of levels of activities. A useful hint is to write a brief description of each activity; this will quickly show if you have reached the task level, i.e. work that would be normally be achieved by one person in one place at one time. A similar guideline can be derived for tasks that are to be fully automated, i.e. that do not require any involvement from a human.

At the task level, the modeller will consider the logical flow of tasks as they combine to complete the entire process. Note that when we initially investigate a process, talking to the stakeholders that do the work, we may well start with the tasks and work bottom up. It is when we design new processes we are more likely to work top down in the manner we have been describing.

Challenges in Creating the Optimal Business Process Design

There are several challenges with this effort of creating hierarchies.
• What to call each activity.
• How to form an activity, i.e. what does an activity look like, how big is it?
• When to stop decomposing the activities into smaller activities, i.e. how will we recognise a task and know that we can stop decomposition?
All of these points are related; we have already referred to them in passing. We will develop the topics in the following sections.

Naming an activity

Activities should be named using a verb-noun or verb-noun phrase., e.g. Fulfil order, Check in passenger, Take booking, Calculate net pay, …..

The name of the activity should reflect its business purpose, or ‘objective’. If you can give a succinct name to the activity, you probably understand that purpose. If you do not really understand what it is supposed to achieve, you probably resort to naming it with a verb such as ‘handle’, ‘manage’, ‘process’, ‘perform’, etc.

To help name an activity, consider its objectives; what is the expected ‘outcome’ or ‘result’ of the activity? What is it intended to achieve? What value does it contribute?

Sharpe and McDermott, always pragmatic, suggest that if we have chosen an accurate and meaningful name for the activity, we can reveal the outcome by reversing the word order of the name, i.e. noun-verb instead of verb-noun. For example, Fulfil Order results in Order Fulfilled. If you had named the activity something such as ‘Handle order’, the result is ‘Order handled’, which is meaningless without a further definition of ‘handled’.

Reversing the word order to uncover the outcome is a great start. You will find it useful to elaborate on that outcome, e.g. what exactly is a fulfilled order? Another useful exercise is to look at all the possible states of order, e.g. ‘provisional’, ‘confirmed’, etc. to see if additional tasks can be identified.

Note that we named all of the activities with singular verbs, i.e. Fulfil Order, not Fulfil Orders. This is deliberate. We will return to this point shortly.

Well formed activities – Cohesion and Coupling

To help us create well formed, solid activities, we can employ the concepts of Cohesion and Coupling. The ideal is high coupling and low, or loose, coupling. We will explore these concepts below, but it’s worth noting that the effort we went to in naming the activities and creating the hierarchy, has got us off to a good start. Cohesion and coupling can help answer the question, “How big is an activity”?

Cohesion

A cohesive activity does one thing, and one thing only. Highly cohesive activities could not be named using a conjunction, e.g. a cohesive activity cannot be ‘Check-in and Check-out client’. If we wanted to represent both of these in a single activity, we should choose an activity name, in verb noun format, that implies both of these things.

Cohesion is demonstrated in the components of a device such as a computer. Components include the disc drive, sound card, memory, etc. Each component has a single job to do; the disc drive is not normally expected to double as a sound card.

Each of these highly cohesive objects typically consists of smaller components, which themselves are cohesive, i.e. each component has a single job to do. So we can identify components, sub-components, sub-sub-components, etc., each of which is cohesive, each of which will have a function that can be named in verb noun format. This is true however high or low we are in the component hierarchy. The same thing should be true of our process hierarchies.
Having trouble naming an activity may indicate that you have not identified a cohesive unit of functionality.

Coupling

Closely related to, and supportive of, high cohesion, we also have coupling. Coupling refers to the interfaces or connections between components. These connections should be minimal and as simple as possible. For coupling, the ideal is loose, or low. High cohesion and loose coupling are mutually supportive. Think how easy it is to replace a component in a computer. A replacement component could even be from a different manufacturer to the original; the interfaces between such components are typically the subject of international standards.
Getting the right names for activities should help to ensure that your process comprises loosely coupled activities.

Cohesion, Coupling and Business Agility

One aspect of business agility is the ability to respond quickly and effectively to change in the external or internal environments in which an organisation operates. An organisation’s processes are key to its intent of delivering value. The more highly cohesive and loosely coupled the activities are, the more responsive an organisation can be to drivers for change. This is not just an abstract theory.

Starting and ending an activity

Events and Outcomes

Activities are normally initiated by a business event. Examples of events are:

• Customer makes an order (Triggers ‘fulfil sales order’)
• Stock level goes below the minimum level (Triggers ‘Purchase product’)
• End of quarter (Triggers ‘Create ‘End of quarter’ report’)

The above are sometimes referred to as:

• External event
• Internal event
• Time event

respectively.

Other terms for ‘initiated’ are ‘triggered’ and ‘instantiated’.

Identifying the triggering event and having a clear outcome, or result, as referred to earlier, facilitates the modeller’s understanding of the intent of the activity. It also facilitates the naming of that activity. Clear delineation of an activity, between its triggering event and its outcome also helps to answer the question about how big should an activity be.

Each instance of an event will occur at a particular point in time. It is separate from all other instances of that same type of event, e.g. one request for a hotel room booking is distinct from all other requests for a room booking.

Similarly, one instance of an outcome is distinct from all other instances, i.e. one booking is distinct from all other bookings.

Returning to the earlier point about naming activities with singular verbs, one instance of an event will trigger an activity to start. Having started, it will either achieve its expected outcome or it will fail in some way to do so. This happens once for each event, hence the verb is singular. We can repeat this singular activity as often as necessary; we do not need to imply this recurring behaviour by making the verb plural.

Inputs and Outputs to and from an activity

Events are typically associated with physical inputs of some kind. E.g. the event, ‘Hotel booking requested’, will be associated with inputs describing the sort of room required, number of persons, start and end dates, and so on.

Outcomes are typically associated with physical outputs from an activity. These may be produced at the end of an activity or at some intermediate point. Exactly what is produced will depend on whether the activity is successful or not. For example, an activity that responds to the event, ‘Request for holiday booking’, is likely to produce outputs such as tickets, travel itinerary, etc. Such an instantiation of an activity would be considered as successful.

An unsuccessful instantiation of such an activity may occur if, for example, suitable dates cannot be found or the price is beyond the customer’s budget.

By considering inputs and outputs we have another aid to defining the appropriate size of an activity.

Sequencing the activities

Having identified the activities/tasks, we can now order them into a logical sequence, as shown in the accompanying diagram.

In fact, delineating the activities/tasks and sequencing them will probably be done iteratively.

Note that each activity/task is complete in itself but it is part of a larger activity or process. Each activity is loosely coupled with its predecessor(s) and successor(s); if there is a human involved in the task, they will understand that as their job.

A manager might be responsible for the whole sequence of activities. We can have a management hierarchy to match the process hierarchy. Management reporting can be done at each level of the hierarchy.

Business rules might apply to each level of the hierarchy. Somebody should have sight of the whole ‘end to end’ process. This oversight will be accompanied by suitable control and reporting mechanisms; it is important that individual tasks are not optimised at the expense of the overall process flow.

Just as each activity and task must be clearly delineated and have a clear outcome, so should each sequence of activities and tasks. This ensures that cohesion and coupling apply at all levels in the process hierarchy. Accountability for performance can be appropriately allocated to staff members. Performance can be measured. Training can be given as needed. Procedures can be clearly defined.

Beyond tasks to task steps

Tasks are usually executed as a series of steps. E.g., in checking in a guest, a hotel receptionist will probably:

Take the guest name or booking reference number
Use the name or reference to retrieve the booking details
Record the arrival of the guest
Complete the allocation of a room to the guest
Etc.

In business processes, there is often no need to create a diagram for the steps; creating a diagram or flowchart may be justified if the steps themselves are complicated. The usual guideline is that we do not explicitly model the process below the level of the task. BPMN for example, stops at the task; below that we have to find other means to document the steps. One form of flowchart that can be used for modelling tasks is the UML artefact, an Activity Diagram.

Conclusion

One key to achieving business agility in business process design is to ensure that you apply the principles of cohesion and coupling. It has worked brilliantly in the design of all living things since, well, since there were any living things. That’s how transplants of body parts are even possible.

It has also worked brilliantly in the design of our machines, where each component has a distinct role and communicates with other components via, typically, internationally agreed interfaces. That is how we can, for example, replace the disc drive in our laptop with one from a different manufacturer.

That’s how software should be designed. This practice is facilitated by using programming languages such as Java that explicitly support the concept of components.

It should be considered in the design of your business processes and other aspects of your architectures.

What is a requirement?

There is no universally agreed, ‘standard’ definition of the term requirement; many groups and individuals will have their own definitions. In general, it is reasonable to assume that a requirement represents something of value to the person or group that expressed it.

IEEE (Institute of Electrical and Electronic Engineers) offers the following definition:

A condition or capability –
needed by a user to solve a problem or achieve an objective –
that must be met by a system or system component to satisfy a contract, standard, specification or other formerly imposed document.

This definition is also used by the IIBA which in turn is referred to in the current syllabus for the BCS Requirements Engineering training course.

There are plenty of other definitions. What we like about the IEEE one is the emphasis on solving a problem and realising an objective. A feature of Capiro’s mission is to help clients to identify the problems, objectives or opportunities before attempting to acquire a solution.

So, in looking for requirements, we could start by identifying the problems that are blocking the achievement of objectives or the realisation of opportunities. An immediate question is, whose problem, whose opportunities and whose objectives? Success with requirements demands that these people, all of them, be identified and engaged with; they must be listened to.

To achieve this aim, it is essential to work with the people most concerned with solving the problem or realising the opportunity; these are the stakeholders. The concept of a stakeholders may also covered by terms such as product manager, product owner, user or actor. Related concepts, terms and roles include change manager, benefits owner, subject matter expert, product champion or evangelist. I have also heard them described as the performers.

requirements elicitation has the potential for conflict — Potential for conflict

A challenge for anyone seeking to understand people’s requirements is that these stakeholders are not a homogeneous group. They are individuals and groups of individuals with individual (or group) perspectives, cultures, ambitions, needs and agendas. They do not all share the same idea of value. Putting all of this together frequently results, to a greater or lesser extent, in conflict. The ‘requirements seeker’, e.g. the business analyst or product owner, needs to be a great facilitator and negotiator.

The potential for confusion is increased with the proliferation of terms such as business requirement, user requirement, software requirement, feature, and so on. These terms are often used interchangeably, even within the same organisation. It is usually a safe bet that the organisation does not have an agreed set of definitions for these terms. Creating a restricted set of preferred terms and definitions would be a great start to improving your requirements process.

Another challenge for the requirements seeker is that requirements are not always expressed concisely, clearly or completely. There is a concept sometimes referred to as ‘customer expectations’. Customer expectations can extend well beyond the expressed requirements. They can be tacit or explicit, realistic or fanciful, creative or mundane. In order to really delight your customers you need to coax these expectations into the light. You then need to really understand them. With the help of other team members, you need to understand if it is feasible to realise them, financially, technically and culturally. And if they are are feasible, are they desirable?

A complete requirements process is likely to include at least the following activities:

Requirements elicitation
Requirements analysis, perhaps with requirements modelling
Requirements recording (documentation)
Requirements management

There are of course various approaches, techniques and tools that can be used to realise the process. We shall cover these in future posts.

Will it make the boat go faster ? Goals and priorities

How to really succeed with anything

Start with one normal guy

The title of this article is taken from the title of a book by Ben Hunt-Davis and Harriet Beverige which describes “Olympic winning strategies for everyday success”. At the start of the book we read, “Ben Hunt Davis is a normal guy. He is also a Olympic gold medallist. How did he succeed?”

Build a team

The philosophy, approach and practices described have a lot of relevance to the work of the business analyst; they have considerable relevance to the analyst trying to work in a more agile fashion.

The book is about :

a team and the individuals that comprise that team
the concern and sense of responsibility for their own outstanding performance and for the overall outstanding performance of the team
It is about a winning team
It is also dedicated to the team’s coach

The book is fairly short and well worth reading. In fact, why not get a copy for every member of your team ?

Learn to pivot

A consistent theme of the book concerns asking, for everything that the team do, “Will it make the boat go faster ?”

In other words, will it help us to achieve what we want to achieve ?

If not, change that thing – or jettison it.

And this really must be applied to everything :

Your goals
The process you follow
The variables of that process
Relationships with colleagues and others

Winners make goals and goals make winners

At the start of the book, Ben points out the importance to his rowing team of being really clear on what they wanted to achieve. He likens goals to magnets – magnets that pull you forward. Studies have shown that people who set goals are more likely to achieve what they want.

In the team setting, identifying goals makes it clear where the team is heading. It also makes clear if there are conflicts between the goals of individual team members. The team needs to know that everyone shares the same vision at the outset, even if that team vision changes in the light of experience.

Ben stresses the importance of making everything open and transparent. This is achieved to a large extent with continual team discussions and reviews. Every goal must be individually important to each team member, perhaps for different reasons in each case. It’s about asking, “What’s in it for me?” and liking the answer. And every team member should understand how the goal will make the boat go faster ; “What’s in it for the team ?”

Extreme goal setting

Ben recommends setting a hierarchy of goals, starting with the “crazy goals”.

Crazy goals are those great ambitions that you might never achieve but which nevertheless provide you with a stimulating vision and a basis for creating a road map to get to where you want to be. Crazy goals are the big things. They are exciting and perhaps a bit daunting. Achieving them probably forces us out of our comfort zones. They are what leads certain teams to excel.

On the negative side, they might also be those things that make us doubt our competence when the road seems long and the going gets tough.

For high performing teams, crazy goals are more than a dream. They are not the equivalent of Harry Potter gazing into the Mirror of Erised and dreaming about things without taking action – those sort of dreams will never be achieved.

Realism and focus

How do you measure up ?

Below the crazy goals we have concrete “measurable goals”.

If you can’t measure them, how will you know if and when you have achieved them ? Ben says that this is like running in a race with no finishing line.

I once worked on a project where I headed up the IT group. The overall project was led by a senior marketing manager. When I asked about the goals for the project, I was treated to a withering look and the response “We will know when we get there”. In other words, “I’ve got no idea what the goals are – I’ve got no idea why we are doing this project or why the bank is funding it”; not a great start for benefits management and realisation.

Know your limits

Ben also distinguishes between those goals that are within your control to achieve and those goals that are outside your control ; this is a critically important distinction if you are to avoid frustration.

For those goals that are outside your control, it may be worth determining whose control they fall under ; perhaps a business analyst can use their influencing skills to achieve change.

Start at the bottom

Finally, Ben suggests that we should have “every day goals”; these provide the detailed, measurable, steps for getting to where we want to be. They are at the bottom of the hierarchy but without them you’re going nowhere.

Know why and know how

As well as understanding the value of setting goals, the effective business analyst will know how to identify and formulate goals ; this may involve using one of the many techniques that exist for modelling goals.

Get personal

It is always worth while challenging your own goals. Consider them and ask yourself, “Is this really and truly what I and the team want or need to achieve ?”

Achieving goals

Winning strategies

Having set their goals, the Olympic rowing team determined strategies for achieving them.

In the rowing team’s case, the strategies included belief in oneself and the team and developing a can-do attitude.

The set of strategies also included, ‘making the journey enjoyable’ ; this is typically a valuable feature of agile approaches.

Ben also points out that you need to know the difference between when it’s time to relax and when it’s time to really focus and get the job done.

Other strategies concerned :

Creating milestones and rewarding yourself when you achieve them
Making yourself hungry for success
Doing things in short bursts or ‘sprints’.

In total, Ben identified eight strategies to fold into the working life of the team.

Agile ?

It was important that all team behaviours were developed by the team. The behaviours were supported by rules that exist to support achievement of goals by maximising performance.

For the Olympic rowing team, the rules were created, changed and dropped by the team depending on whether or not they were seen to make the boat go faster. Business analysts might do something similar with development methods and approaches, techniques and standards.

The rules were :

Constantly discussed
Simple
Bought into by everybody

The parallels to agile team work are obvious.

It’s not what you do it’s the way that you do it

Focus on the process

One interesting recommendation is to concentrate not on the result, but on the process that delivers that result.

Within a process there are variables that can be changed and experimented with to see what really does make the boat go faster.

Teams must discover what works for them, for their type of project in their industry, their organisation, culture, management policy.

Throw away the rule book

In the world of the business analyst, this could well mean throwing away the standard rule (recipe) book and devising your own approach. Remember to measure everything to ensure that your approach is bringing you closer to the finishing line and the achievement of your goals.

Give it some wellie

Ben recommends discussing the variables and agreeing as a team which variable or subset of the variables should be focused on for the next few weeks. Work smarter, not harder or longer. Get really focused for brief periods, then meet and reflect.

When the going gets tough, the tough get …. gone ?

Of course working in a team, as with any relationship, has its challenges. Everyone who has worked in a high performing team which demonstrates great motivation, moral and results knows how great it can be to be a member.

But what happens when the membership of that team changes ?

What happens if there is one person not pulling their weight or one person that you really wish would find somewhere else to work ?

Such things can and will slow down the boat. Strategies are needed to deal with them and to turn negatives into positives. The book contains advice for handling these situations.

Start as you mean to go on

Success starts by setting goals, big crazy goals and smaller, measurable and achievable goals.

Measure all the time and change your process according to what works for you and your team ; do not change just to fit in with the prevailing wisdom.

Only you and your team know what works for you

Only you and your team know the constraints that your environment forces on you

Only you and your team know each other’s strengths and weaknesses, personalities, attitudes and biases

As is advised in many Kanban circles, start from where you are and then go for continuous improvement, one bit at a time. Focus on what really does make your boat go faster.

Applying Kanban to agile business analysis

Are you at the mercy of your environment?

Consider the things that limit you the most when trying to do your work as a business analyst. They probably include at least one of the following:

Being overloaded with work
Lack of a clear idea about what you are supposed to be achieving
Constantly needing to switch between tasks
Being slowed down by bottlenecks in the process
Working to estimates made by ‘someone in management’ who has no direct link to the process
Working to frequently changing priorities imposed by the person or group with the loudest voice and the greatest clout
Reactive (crisis) management
Lack of cooperation among teams
Resistance to change

You perhaps feel that you are subject to control by people whose management philosophy is based on the premise that nothing is impossible to the person who does not have to it themselves. You may also feel that you work in an environment where the normal laws of physics are suspended so that sound travels faster than light.

Can Kanban make your life better?

In 2010, David Anderson wrote a book entitled, ‘Kanban’.

Kanban seemed to offer a solution that could help resolve the sort of issues mentioned above.

I do not intend to try to give a full description of kanban in this short article. There are plenty of books and articles available; you might start by reading David Anderson’s. However, for those who are not familiar with kanban, here is a list of some of its characteristic features.

Limits work in progress (WIP)
Participants at any particular step in a process ‘signal’ when they are ready to accept more work; it’s a ‘pull’ rather than a ‘push’ model
Emphasises visualisation and transparency
Incremental and iterative. (evolutionary and incremental)
Helps to produce a sustainable pace of work
Fundamental to continuous improvement
Starts from where you are now and seeks to improve things

The Kanban approach is to ‘pull’ work on request. ‘Pushing’ work from one step to the next can cause the recipients of that work to become overloaded. Furthermore, each step in a process has defined limits for the quantity of work in progress that it can handle at any one time; the team involved in that step will not allow those limits to be exceeded and only they can say when they are ready to accept more work. This has the effect of creating a sustainable pace of work, without exhausting the team members.

Perhaps counter intuitively, limiting the work in progress can increase the overall throughput. Consider, for example, what is sometimes called the ‘motorway effect’ on major roads. Traffic is snarled up and just as you are thinking that there must be dreadful accident ahead, the traffic suddenly clears for no apparent reason – there was no accident or other obstruction. Such bottlenecks typically result from the sheer volume of traffic. The effect is defined mathematically in queuing theory.

Kanban is iterative and incremental implying, among other things, that teams do not try to do too much too soon. We see here an application of the ‘minimum viable product’ approach.

The introduction of kanban can see the emergence of other desirable features such as co-operation between teams and the facilitation of culture change.

Kanban and agile business analysis

The business analyst is concerned with identifying problems and opportunities and then specifying the goals and requirements for a solution to those problems or the realisation of the opportunities. How often do we feel that we are pushed by others into identifying requirements and solutions before the problem have been properly understood?

In a process based on kanban we are saying that the analysts will not request the next task until they have determined what the problem is, obtained general agreement on the business goals and priorities for a solution and then discovered the requirements for that solution. This sounds good. Of course, the analyst must not abuse the system by causing the old problem of paralysis by analysis. Transparency and visibility of the process should prevent that undesirable situation.

To properly determine the nature of problems and obtain common agreement as to what the problems are, requires the cooperation of a number of parties. Similarly, to get common agreement on goals for a solution requires cooperation between concerned stakeholders. Such cooperation is a feature of kanban. The insistence on visualisation and transparency demands that concerned parties work together. When parties cooperate in an open manner, it is easier to highlight differences of opinion and to negotiate a common vision and approach for the way forward. Visibility and transparency help to prevent disembodied voices in the background from adversely impacting the process.

Is kanban really the answer?

At a thought provoking talk I attended a while ago, the speaker, a highly experienced agile consultant, said that the examples in Anderson’s book spoke about software maintenance rather than software development and were not relevant to the latter. He also claimed that Kanban was not the thing that was going to prevent more catastrophic software failures from occurring in the future. For the record, the Speaker also said that Scrum was not going to help in that regard either.

Kanban was born in a manufacturing environment which is concerned with processes that have predictable steps. Software maintenance can perhaps be similarly categorised. But software development concerns innovation, novelty and unpredictability, all in the name of seeking business advantage. Actually, Anderson’s examples from Microsoft did concern software development, but let’s leave that aside for the moment.

When I first read Anderson’s book, the thing that intrigued me the most was not so much whether or not kanban was directly relevant to the process of developing novel software, but that it appeared to be the catalyst for many emergent features. These features might possibly be surprising or counter intuitive, but at least some of them could lead to the development of an environment that would support software development whatever process was actually used.

Anderson went on to say that kanban supported, and even encouraged, teams to develop their own processes according to the context in which the teams were working. He predicted that kanban, properly understood and applied, could lead to the demise of one size suits all processes along with any schemes that promote them. I loved the sound of that.

I constantly stress the importance of context and of defining a project approach that is appropriate to that context. I also have a natural suspicion when people say to me, “If you do it exactly like this, all your problems will be resolved”. Similarly, I am suspicious when people say that if you don’t do a particular task in a particular way, you are bound to be wrong. Actually, when I try my hand at cooking, I do follow recipes to the letter and, in the context of cooking, the above statements are generally true; if I don’t follow the recipe exactly, the results are a disaster.

But the above statements are not true in situations that are novel and unpredictable. I once provided consultancy to a very large project on which I was asked to extend their methodology to cover every conceivable situation – a job for life that could never be achieved.

The main reason I take the above mentioned approach to cooking is because I am not an expert chef; these guys make their own rules, but only after developing a profound understanding of the basics. Software experts ought to be able to the same. Professional developers, should be able to tailor approaches to specific situations and contexts. They should not do things just to comply with a particular statement in the agile manifesto, for example.

Context is affected by both hard and soft factors such as the business goals, strategic importance, culture, risks, budget, the project scope, the project team, the processes, data and business rules that impact the project, etc. Kanban gives people permission to be non conformist. This is not done for the sake of non conformity but to match their process to their situation. Kanban therefore encourages diversity, even between teams in the same organisation.

Kanban principles

To be able to define a process that is appropriate to any given context, it is important to have an agreed set of principles rather than a recipe. This allows teams to develop context dependent processes whilst maintaining a core of common understanding and agreement.

The business analyst is, or should be, involved in the project from the outset. They are therefore in the right place at the right time to affect how the project should proceed. They are natural partners of project managers, product managers and product owners. If all of these groups, plus representatives from architecture, design, development and testing share a set of commonly understood principles, they are well placed to cooperatively define context dependent processes.

Anderson describes a set of principles, or properties, that kanban uses to cause the emergence of lean behaviours in organisations :

visualise workflow
limit work in progress
measure and manage flow
make process policies explicit
use models to recognise improvement opportunities.

Anderson goes on to define ‘6 Steps for success’ which he unfortunately calls a recipe.

focus on quality
reduce work in progress
deliver often
balance demand against throughput
prioritise (a responsibility of the business, not IT)
attack sources of variability to improve predictability

Moving from top to bottom down the list, we go from things that can be done independently of other groups to things that require cooperation with other groups.

Implementing a kanban based system

The business analyst should concentrate first and foremost on the quality of their work. Do they have the right skills for the job and are those skills honed to perfection ? Is there a Business Analysis Centre of Excellence within the group ? Is the analyst able to quickly and consistently identify the business problem, place it in the context of business goals and strategies and define the optimum approach to a resolution of the problem ? Is the analyst capable of skilfully managing negotiations, presenting their viewpoints, and defending those viewpoints logically and rationally, whilst also taking on board the viewpoints of the whole team ?

If you, the business analyst, are trying to reduce your work in progress, it is essential to be able to calculate the amount of work you can handle at any one time in order to maintain a sustainable pace. It is your skill as an analyst that enables you to do that work as quickly as possible, whilst maintaining quality and satisfying the demands of the business. You are seeking to prove that limiting work in progress will result in increased throughput with higher quality and therefore higher business value.

You are also seeking to identify bottlenecks in the process and to remove them one by one. These effects will be reinforced by increasing collaboration and developing more effective relationships between groups. You are seeking to achieve the viral spread of these practises across the organisation. This may take time. Eventually, you are also looking to see a better work life balance for you and your fellow team members.

Marketing yourself as an agile business analyst

As an agile business analyst, you should ensure that the quality of your work is recognised both within the business and within the development teams. As your reputation as an analyst increases, you are more likely to be able to influence other stakeholders and to gain their cooperation and acceptance in order to move progressively through the six steps. Anderson has demonstrated that this is an effective approach to reducing resistance to change. As an analyst, and therefore an agent of change, this is worth taking on board. If you think there is a way of applying Kanban to your business analyst role, give it a go.

Overcome the fear and deliver a great presentation

Scream - Extract — “I’ve just been asked to give a presentation”

Learn to enjoy it

In surveys about what people fear the most, the commonest answer is, apparently, not snakes, sharks or spiders, but having to stand up in front of people and deliver a presentation.

But delivering a great presentation can help you stand out as a business analyst. In fact, presentation skills are a business analysis core competence.

Ambitious business analysts can take advantage of the fact that so many people don’t want to present in public. Delivering a great presentation to an influential audience can be a career enhancing experience.

Sure, we can all get a bit nervous just before a presentation. The great speaker, Winston Churchill, admitted that he got butterflies in his stomach before a presentation. But he added, “I taught them to fly in formation”. In this article we look at some simple ways of getting your butterflies to fly in formation.

As with so many things, from decorating a room to climbing Mount Everest, delivering a great presentation depends on planning and preparation.

GREAT PRESENTATIONS START WITH BOSCARD

In a consultancy that I once worked for, we defined terms of references for our projects with the help of the acronym B0SCARD. We can use the same acronym, more or less, in preparing for our presentations. B0SCARD stands for,

Background
Objectives
Scope
Constraints
Authority
Responsibility
Deliverables

The BCS International Diploma in Business Analysis uses a similar idea but limits it to OSCAR.

We’ll make a slight adjustment to one of these terms in preparing for a presentation rather than for a project.

Background. Why are you going to deliver this presentation? What was the situation that led to this? Thinking about why you are where you are, can help you focus on what you really need to deliver and to get across to your audience. No need for a long document here. Try to capture the background with a few succinct bullet points.
Objectives. This follows on from thinking about the background. What exactly is the purpose of your presentation? What message are you trying to get across to your audience? Is a presentation really the best way of achieving this? What might you try, instead of or in addition to, the presentation. You need to achieve laser sharp precision on what you will talk about and why you will be talking about it.
Scope. As with projects, keep the scope of your presentation as focused as possible. This will help to keep your presentation as short as possible. Think of advertisements on the television. They may annoy you, but consider how they managed to get across their message in a very short space of time. Some short sharp adverts stick in people’s minds for a long time. That’s what you want to achieve with your presentation. And obviously you want it to stick in people’s minds for all the good reasons, not the bad.
Constraints. The obvious constraint is time. It is unlikely that you will need to present for more than thirty minutes, and typically it will be for a lot less. Other constraints may be for things like the amount of time you have for preparation, the room layout, the media and technology that you will use, et cetera. Get answers for all of these points as soon as possible. If necessary, make assumptions then get those assumptions clarified early.
Audience. Okay, in project planning, ‘A’ stands for authority. But the presentations, the important thing is the audience. You need to know as much about them as possible. Who are they? What are their viewpoints? How senior are they? Why are they coming to your presentation? What do they want to get out of it? Are you likely to say anything that they will disagree with? Do they support the same ideas as you? Have you talked to any of them, informally, about your planned presentation? if not, perhaps you should.
Responsibility. This is more relevant if you’re going to give a group presentation. You do need to work out which member of your presentation team is going to do what. For example, who is going to introduce and wind up the presentation? What particular topic will each of the speakers handle? Who will take the questions on costs or estimates?
Deliverables. Divide this section into two. First, consider the things that you will need to create for your delivery, such as your notes, your visual aids and your handouts. As well as thinking about such physical deliverables, think about the mental or emotional ones as well. What feelings do you want your audience to go away with? Do you want to have convinced them to take a certain course of action? Do you want to convince them that you have the capability to do a good job on the business analysis for this project or that you can guide them on the path towards, say, creating a business analysis centre of excellence or moving to agile analysis?

How to interview – A core skill for the BA

An interview with 2 people — One to one interview

Fact finding is at the heart of the business analyst’s job. One of the most popular and effective means of fact finding is the interview. Knowing how to interview is a core technique for the business analyst to master.

Admittedly interviews do have their limitations and should be used in combination with other techniques such as facilitated workshops, but they are nevertheless very valuable; at least, they are when it is used properly.

Even if you work in an agile environment that focuses on facilitated workshops, you will find that one to interviews are a useful alternative, or supplement; this is particularly true when dealing with senior managers.

An interview is also valuable when trying to get detailed information from someone; you probably do not need a group of people to help you do this.

This article provides simple guidelines for conducting effective interviews. As with many things, running an effective interview starts with effective planning and preparation. Following that, you can conduct and follow up the interview.

Planning

BOSCARD. I introduced BOSCARD in the article on presentations. This can easily be adapted to preparing for an interview. Obviously the amount and time spent on preparation needs to be proportional to the job at hand.

Objectives. At the very least you should be clear on the objective of the interview and what information you want to gather. As soon as you think you know that, ask yourself if an interview is the best way of obtaining that information or would a workshop or questionnaire be more efficient and effective. Being clear on the objective(s) of the interview will help you know what you need to come away with and what success will look like. It will help you to structure the interview into topics and questions.

Interviewee. When planning a presentation, you need to know your audience. For an interview you will normally have an audience of one, occasionally two. During the interview you will be taking that person away from their usual job. Make sure that you understand what that job is and the seniority level of the job holder. Thorough planning and preparation of your interview should:

minimise the time that you will need to request from the interviewee
maximise the benefit to yourself and to your project

If you need the interviewee to bring anything to the interview, let them know in advance.

If you are at the start of planning a series of interviews, decide on the roles and possibly the individuals that you will need to obtain information from. You will typically want to start with the most senior people to get the big picture and perhaps the authority to interview their team. Senior people can sometimes become unavailable at short notice because of things that crop in the business. Try to get these people onto your calendar early but do not be surprised if it turns out that they become the last people that you actually interview.

Scope. It is important to go into an interview with a clear set of prioritised and sequenced set of topics that you want to cover. When planning the interview, identify and prioritise your topics. All topics should relate to the overall objective of the interview. We will return to this when considering timings for the interview. Also, decide on the level of detail that you need and ensure that this is appropriate to the role and position of the interviewee.

Constraints. This relates particularly to the date, the time and the location. The date needs to be agreed with the interviewee or their PA. Normally an interview will last between 30 and 60 minutes. Agree this with the interviewee. Another constraint is the number of interviewers; normally this is just one person but occasionally it may be advantageous to have two – we will return to this point later.

Deliverables. What needs to come out of the interview? Physically this will be the notes and perhaps sample documents gathered from the interviewee. Also consider what you want to come away with in non-physical terms; for example, if you have just interviewed the project sponsor for the first time, you probably want them to go away confident that you are the right person for the job.

Preparation

Sequence the set of topics that you identified during planning. When preparing the interview, start with the most important topics in case you run out of time. Try to ensure that there is a logical flow between topics and, if you have them, between sub-topics.

Once you have the topics in sequence, consider what your key, or opening, question will be for each topic. Try not to write down too many questions in advance; an interview is about listening and responding, so keep detail to the minimum necessary for achieving your objectives. However, if there are important supplementary questions, make a note of those too. This is shown on the accompanying diagram.

If there are sensitive topics to be covered, you will probably want to tackle them later in the interview, once rapport is established. If you started a series of interviews by speaking to the sponsor, they might have warned you about potentially difficult areas; ask the sponsor directly if they are aware of any difficult or sensitive areas.

You should also create a time plan. During the interview, it is important that you do not exceed the time allocated for each topic. When planning the timings, you can quickly and easily see if your scope is too ambitious. Consider the accompanying diagram which shows the interview plan in the form of a grid.

The topics are laid out left to right in priority order. As mentioned earlier, the typical time for an interview is between 30 and 60 minutes. You will normally allow a brief period for the introduction and a slightly longer period for wrapping it up. For the example, I have allowed a total of fifteen minutes for these two items.

The example in the grid indicates that I am planning to cover three topics, and, to simplify the example, have allocated an equal amount of time, i.e. fifteen minutes, to each of them. If I have sub-topics, you can easily see from the grid that I could be pressed for time.

An interview should be as brief as possible but you do not want to rush it; better to reduce the scope and, if necessary, plan a series of interviews to capture all of the required information; perhaps each will involve different staff and different degrees of detail, as appropriate to the particular interviewees.

You can of course send your interview plan and key questions in advance to the interviewee. They can tell you if they are the best person to talk to. They might, for example, tell you that for the information you require you need to speak to a more senior person. Alternatively, they may suggest someone with a better understanding of the detail that you need. Perhaps your intended interviewee might even send you an immediate answer to all or some of your questions as well as possibly providing other information that they feel is relevant.

It is often useful to plan the introduction and summary for your interview after you have completed your planning for the body of the interview.

Conducting the interview

Introduction

The statement that ‘You only get one chance to make a first impression’ is normally true. If the interview will be the first time that you have met the interviewee, you should take that statement to heart, particularly if your interviewee is a senior manager. Apart from anything else, it is basic politeness to turn up on time; it is also professional behaviour.

At the outset, check that the interviewee understands what the interview is about. The interview may have been put on the calendar by their PA so do not take anything for granted about the interviewee may or may not know or have remembered. Check that they are still ok for time.

The body of the interview

Follow your interview plan. Place it on the desk in front of you so that the interviewee can see it; this will also remind them, if necessary, about how much time has passed and how much you still wish to cover. Having the plan on the desk, rather than clutched close to your chest or chin, should allow you to talk more freely and naturally; it also makes it easier for you to take notes on a separate note pad.

You have a timing plan to follow but be relaxed and do not pressurise the interviewee. Build up a rapport as quickly as possible.

Ensure that your questions are open. Open questions are those that allow the interviewee to speak. Examples of open questions are,

“Could you take me through the steps of this task”.
“Could you tell me how you manage to control all that activity during the busy periods”.

Ok, they may just answer ‘yes’ or ‘no’ to the above, but they are unlikely to.

Closed questions are those that invite yes or no answers. For example, “I understand that you always check 100% of the samples – is that correct?

Be very careful with certain forms of closed question. For example, a statement such as, “I understand that there have been big problems with stock control since you took over. Is that true?”, is unlikely to do anything positive for the rapport!

Listen carefully at all times. Let your body language show that you are listening and that you interested. If you start thinking about other things or are distracted by something happening outside the window, you may well miss something vital and it is hard to recover from that; you may not even realise that you have missed something vital. Periodically confirm your understanding verbally, or by nodding; be aware that different cultures may interpret a nod differently from how you do.

Whilst following your plan and your timings, be prepared to respond to something that was said and go off plan when necessary. You are listening for ‘leads’. A lead is something that prompts you to ask for additional information. It will not be on your plan. In fact, it may conflict with information that had before coming to the interview.

Also be prepared to supply feeds. These are prompts to the interviewee to supply information, perhaps based on something they said earlier. Feeds will not be on your plan.

If you do not understand something that the interviewee said, it is vital that you ask for an explanation. Do not be afraid of saying that you do not know; far worse is to pretend that you do.

Note taking

Note taking can be a challenge, particularly if the interviewee talks a lot and / or talks rapidly. However senior the interviewee, you are in charge of the interview. Where necessary, ask the interviewee to give you a moment to make a note of something; apart from anything else, it shows you are interested in what is being said.

Do not forget to ask the interviewee if it is ok with them that you take notes. They may ask what you intend to do with them and who might see them. You reassure them by telling them that you will let them see the write up of the interview before releasing the information. At certain points in the interview, they may tell you that something is ‘Off the record’.

If you have the resources available, it can be effective to have two interviewers, one to ask most of the questions and one to take most of the notes. If you are the one asking the questions, occaisionally ask the note taker if they are keeping up, or if they captured a particular point.

Diagrams and models can be great way of note taking if appropriate. Again, keep the diagram visible to the interviewee; even if they have never previously seen a particular form of model, I am often impressed at how quickly business stakeholders will pick up the technique and start using it with me. It is often claimed, for example, that you should not try to teach data modelling or state modelling to business stakeholders because they cannot possibly understand it. If you are modelling their business, and your model reflects the language that they are using, I have seen them not only understanding it, but coming up with some great insights based on an instant analysis that the model allowed them to make. I have had business stakeholders at the end of such a session telling me that the model and the act of modelling gave them fresh insights into their own business. You may find that what started off as an interview at a desk becomes a stand up affair at a white board or a flip chart. Don’t forget to photograph or otherwise capture the detail on the whiteboard.

Recording. When I worked with dealers and money brokers in the city, I often found that it was helpful to record the detail of the interview, particularly when the dealer spoke very rapidly in the language of the dealing room; by ‘language of the dealing room’, I’m talking about financial terminology, not some of the other language you hear. If you want to record, ask the interviewee if they mind.

Summarising the interview

End the interview at the agreed time unless the interviewee says that it is alright to continue. Go through your notes with the interviewee and ask them to confirm that what have written is correct. Amend any misunderstandings immediately.

Remind the interviewee that you will provide them with a write up of the interview and that you will wait for their acceptance before circulating them.

Thank them for their time and ask if it will be alright to come back to them if necessary for follow up information.

Follow up the interview

Write up your notes immediately. For this reason, you should always ty to avoid having ‘back to back’ interviews or planning for interviews at the end of the day; this is especially true if the day is Friday or there is a public holiday the next day.

As well as writing up the notes, incorporate your findings and analysis into the other work that you and your team are undertaking. Your analysis might indicate that you need to have further meetings with your interviewee or that you need to see other stakeholders to gather supporting information.

Summary

Requirements elicitation – 8 Steps to requirements success

Go for business value – Not blind adherence to a particular approach

The way that you undertake requirements elicitation and management gives credibility to your requirements specifications.

In order to achieve this credibility, you need to design your requirements elicitation process to deliver business value whilst being flexible enough to adapt to any software development and project management approach, agile or traditional.

This post, ‘Requirements elicitation – 8 steps to success’, outlines an approach in which the steps collectively aim to:

Take a risk-based approach to requirements discovery, optimising the amount of effort devoted to requirements elicitation and analysis
Understand the stakeholders and their differing perspectives
Understand the business, architectural and technical context for the development
Understand the problem to be solved or the opportunity to be realised
Encourage partnerships with business stakeholders, product managers and product owners to remain focused on collecting requirements that will solve the business problems at hand
Encourage partnerships with project management to ensure that the process is embedded in best project management practice
Encourage partnerships between business analysts, architects, designers, developers and testers to efficiently develop effective and valuable products
Establish benefits, risks and costs of each option for the architecture of a solution
Deliver fast and deliver frequently
Start with the project scope as small as possible and deliver something useful – then enhance it as needed by the business
Discourage sacrificing speed of delivery for imagined ‘perfection’
Accept that compromise based on rational argument is essential

This article assumes that requirements can come in many forms, e.g.

Traditional (atomic), usually starting ‘The user shall …,’ or ‘The system shall ….’
Use cases and scenarios
Agile style epics and user stories
Acceptance criteria
Decision tables
Requirements models, etc.

I believe that, with some fine tuning, the approach described here can be applied universally.

Step 1 – Establish an approach to requirements management

Requirements management has several aspects, including requirements identification, version management, change management and traceability. However effective your other requirements processes become, they are unlikely to count for much if you cannot manage these things. As an experiment, review some work in progress among your of your teams and then consider the following:

Are different teams referring to the same artifact (requirement, user story, task description, model, …) by different names or identifiers?
Are different teams each working with a different version of what should be the same requirement?
Are developers discovering problems in requirements that you thought had been sorted out?
Is anyone unable to answer questions from a product manager or a developer on why a particular user story is necessary?

If the answer to all or any of the above is no, then you don’t appear to have an issue at the moment. But if the answer is yes, it’s worthwhile taking a closer look.

Make your requirements management approach as lightweight as you like, as long as it’s not a ‘house of cards’.

Let’s look briefly at each of the aspects of requirements management mentioned above; these aspects are all related.

Identifiers

Unless you have an approach to requirements that avoids documenting or retaining anything, you need to have a means of uniquely identifying your requirements artifacts. A unique identifier is the minimum you will need to be able to manage any item created in the development process, including requirements in all their forms.

An identifier is typically a simple number, with no built in significance, e.g. it does not represent a cost centre or anything else that could potentially change over time; an identifier must remain constant for its whole life.

Version management and baselines

Hopefully nobody these days is working with the assumption that requirements will not change. For years preceding the agile movement, well run projects have accepted that this is not a realistic scenario. Therefore, to guarantee the uniqueness of an identifier, it needs to have a version number; your version numbering system should be as simple as possible but must be applied consistently and universally.

The version number needs to be updated whenever the associated artifact changes. And to be able to have confidence in the version numbers, you need a process, however simple and lightweight, that ensures a minimum effective control over changes to those version numbers.

When a particular version of an artifact has been approved, that version should be regarded as a ‘baseline’. Never directly alter a baseline. Instead, keep a copy of it then update the version number; you can now make changes to this new version.

You need to be able to quickly, confidently, and preferably effortlessly, roll back to earlier baselined (approved) versions if the situation demands it. To repeat, the copies of previous versions are all referred to as baselines; a baseline is never discarded.

Managing change

Managing change is sometimes referred to as change control which is perhaps an unfortunate term as it sounds as though it is a mechanism for suppressing change.

Change control is not an attempt to prevent change, but to ensure that:

A change is not made on a whim
All parties fully understand the impact and risks in making the change
There are no unexpected and unwanted side effects of the change.

These things are particularly important on large and complex projects, and even more particularly in highly regulated industries.

In the early stages of a project, change is probably happening all the time and should not be bureaucratically controlled.

Once a baseline has been established, some control is necessary. If there are sound reasons for the change, business or technical, then it should be allowed to happen.

Some changes need to be applied immediately. Other changes can be batched and applied together in the next release.

Obviously, the change control mechanism should be as lightweight as possible in a given situation. You might consider having a hierarchy of change control bodies, from very informal, local boards, to more formal, programme wide boards. Such a hierarchy needs to be shallow so that decision making can be performed quickly.

Traceability

Another aspect of requirements management is traceability. Look to see if anyone on your project team is asking where certain requirements or completed software came from, querying their relevance to the product objectives or asking why a product has been built in the manner it has?

If the project is conducted in a highly regulated industry, someone will definitely ask these sorts of questions; if a requirement or software function is not needed, then it should not be there.

If you operate a lightweight development process with co-located project team members, producing software in short iterations, perhaps you have complete confidence that you can sort out issues of relevance and value as you go, as a natural part of your process.

But whether you rely on written or purely verbal communication, traceability is important. In an audit following a software disaster, it may be more than important.

Configuration Management

Requirements management is a sub-set of configuration management and similar principles apply. And yes, there are lots of tools out there reasonably claiming to be able to meet your requirements for requirement management, but if you don’t have a robust requirements process in place you are unlikely to be able to obtain the return on that investment. In the worst case, the tool gets jettisoned and perhaps wrongly blamed for the failure to deliver what you expected.

At the start of this article, I proposed taking a risk based approach to requirements. Configuration management may be considered as an aspect of risk management. It is a business matter to determine and assess risks and to develop policies and rules that reflect desired responses to risks; these policies will reflect the level of risk that an organisation is prepared to tolerate. It is presumably the CIO or IT Director who is accountable for ensuring that IT practice supports those business policies and rules.

A robust but simple and flexible requirements management process, appropriate to the criticality of your project, the nature of your industry, and the business policies and rules applicable to your organisation, should help to increase your speed of development, reduce the chances of errors and rework (waste and scrap) and facilitate management of priorities and release candidates.

You can get this in place before writing a single requirement or building a single piece of software. And having set up a process that is as simple as possible, it can be iteratively refined in the light of experience.

Once an approach is agreed, it should only need fine tuning for each project. It should support projects, not get in the way.

Step 2 – Establish the system context

The following description has been written from the perspective of business systems rather than, say, embedded systems. I therefore tend to talk about the ‘business context’; the word business is being used very generally to include non commercial organisations. However, all systems will have a context, environment, or domain, in which they operate and within which the problem to be investigated lies.

This context will impose constraints on the solution to the problem. We refer to the ‘problem domain’ that defines the scope of the problem and the ‘solution domain’ that defines the scope of the solution. Typically we will need to progressively refine our initial ideas for both of these.

Business Problems, Objectives and Opportunities

Determination of the business context will typically involve determining the real problem, objective, opportunity or challenge that is affecting the organisation.

The problem may well be blocking the achievement of your organisation’s objectives. It is important to get to the root of the problem; this will allow you to develop a solution that offers the greatest value. This activity happens in the business domain and may occur well before there is any decision on whether or not to develop a software solution to the problem.

Opportunities do not generally last for long in today’s competitive environment. We need to act fast, making decisions about what to pursue and what to ignore.

Business (Feasibility) Study

For larger projects and where the nature of the problem or opportunity is unclear, we may well find it useful to undertake a study, sometimes referred to as a business study or, perhaps as a feasibility study.

This should be run as a project in its own right and will typically involve experienced business analysts and business architects working with business people, subject matter experts and relevant technical experts such as enterprise, data and solution architects.

The objective of the study is to get to the root, the essence, of the problem or opportunity and to recommend options for the way forward.

The business study should identify the size and impact of the problem, the areas affected and the priority for taking action.

The pace of change in modern organisations demands that such studies are quick but their recommendations must be well founded.

Business Processes, Rules and Concepts

Establishing the business context should also involve identifying which processes, rules and data you are concerned with in analysing and solving the problem.

Sometimes the problem can be the process, the rules or the data themselves. What we have called a business study may well be an investigation into the current business processes, business data or business rules.

Case for change

If the above activities suggest that there is a case for change, it needs to be developeded to the point where it can influence the right people to call for the change to be made.

The case for change may have to be ‘sold’ to the organisation. This is the point at which an initial vision can be developed.

Additionally, initial ideas about the size and impact of the change can be assessed.

Continual and iterative improvement is often thought to be more appropriate, feasible and effective than radical change. The best advice is often to keep it as small, simple, understandable and as manageable as possible. There should also be a groundswell of support for the change. Pushing boulders downhill is easier than pushing them uphill.

The goals for the change, and the justification for the investment in the change, need to be clearly defined and prioritised. These might be considered as the real business requirements.

Initial Business Case

All of the above should feed into the development of a business case, which may be formal or informal depending on the circumstances.

The business case should define the benefits and value proposition which in turn should link back to the business objectives and be compatible with the organisation’s strategy.

Although IT may propose that something is a benefit, it is up to the business to accept or reject such proposals.

The initial business case should endeavour to identify the risks. assumptions, constraints costs and benefits of the change initiative.

Implementation of the change may involve one or more projects or even programmes. An initial road map for the change can be established.

Project Approach

Once the potential programmes or projects have been identified, you are in a position to clarify the objectives, scope, constraints and deliverables of each project.

You can also identify the most appropriate approach to running it.

Typically, optimising the scope means minimising it and identifying the minimum viable product.

Your chosen project approach should be determined by:

The nature of project
The culture and experience of the organisation
Known constraints.

Unless there are compelling reasons for delivering a product or service in one go, we would normally recommend taking an iterative, incremental approach to product development.

Project Management

Critical success factors for requirements discovery and analysis are very similar to those for project management. Ideally you should integrate your project management or team leadership approach with your approach to requirements; we appreciate that some teams may have a cooperative approach to leadership and management.

Having identified the business context, your team will be able to more effectively identify the vision, objectives and scope for the desired product or service and consequently for the project that will deliver that product or service.

Step 3 – Stakeholder Analysis and Management

We should not normally proceed any further without refining our view of exactly whose problem we are trying to resolve; the problem owners are the stakeholders.

We need to identify and understand these stakeholders, the product owner(s) and the product manager(s). There are a number of approaches that can help you with stakeholder identification, stakeholder analysis and stakeholder management.

In any requirements elicitation initiative it is vital that all stakeholders are identified. To miss one could well guarantee that your requirements will be incomplete or will contain hidden conflicts.

Step 3 should actually commence at some point during step 2.

Stakeholder Perspectives and Goals

It is important that we have a clear understanding of the perspectives, or viewpoints, of the various stakeholders.

If you have identified a single product owner, that is fine as long as they really can represent the viewpoint of all the other stakeholders that have a valid and relevant opinion on the matter.

If there is more than one stakeholder involved, you can guarantee that collectively they will have a variety of perspectives and a variety of opinions about the nature of the problem and the solution. You need to analyse these perspectives and work with everyone involved to reach a common understanding; this is often easier said than done. You need to understand just how critical each stakeholder is to the project; be clear as to how much weight their voice carries. There is a clear link between stakeholder management and project management.

This is the time to ascertain individual stakeholder goals for a solution to the problem;

Are these individual goals conducive to the realisation of the project goals agreed so far?
Do the goals of any one stakeholder conflict with the goals of another?

The business analysts will rely on their negotiation and arbitration skills. It is not always easy to resolve conflicting goals, but if it is not done immediately, things will get even more difficult when trying to agree the more detailed requirements based on those goals. There are recognised techniques for goal analysis and conflict resolution.

Take a look at the soft system approaches pioneered by Checkland and Wilson.

Team Building

In most projects, the team is all important in achieving a successful outcome to requirements elicitation.

Our approach to team building is to ensure that teams should contain not only business analysts, but also business people, subject matter experts, architects, developers, testers and various specialists. This is a typical multi disciplinary team (MDT).

Such a team can become highly motivated and demonstrate great morale.

Some people prefer teams of specialists, others prefer teams of generalists; there is probably no single right answer on this one, and circumstances should suggest the best approach.

We may also define an extended team structure, ensuring that all stakeholders are effectively but efficiently represented; we include both business and technical stakeholders.

Finally, your general approach should continue to demonstrate close liaison with project management, however the management or leadership team is constituted.

Keep me about informed course launches and special offers

Step 4 – Determining a Strategy for Requirements Specification

Specification styles can vary between the informal and the formal. They can also vary between sparse and comprehensive and between mainly spoken and mainly written. The choice of style can depend on a number of factors, e.g.

Project stage

Early in the project the requirements specification can be very informal. Post-it notes and white card are commonly used to capture early ideas. Later in the project a fully documented catalogue of ‘traditional’ requirements, use cases or user stories, can be created. They may perhaps recorded on a suitable requirements management tool,

Risk

What is the impact if something goes wrong with the product? What is the probability that this could happen? Is the project intended to create a strategically important customer facing product or is it to implement a simple change to a back office system? How familiar are you with developing this type of product? Is the development being done off shore or in-house? Are the business owners, analysts and developers all co-located? These are the sort of considerations that affect risk. A general rule of thumb is that the higher the level of risk, the more formal should be the approach to contain and manage those risks.

Purpose of the requirements documentation

Are the requirements and user stories intended for a bespoke development, the purchase of a software package or for an invitation to tender? Will the requirements document be used as the basis of a contract?

Non-functional (quality) requirements

What is your approach to architecturally significant and the full range of other so called, non functional, requirements?

Project approach

Will the project be run according to a waterfall approach, an iterative, lean agile approach or some mix of these?

Company culture

What is the preferred house style? How comfortable is the business in living with risk?

Preferred requirements style

Do all of your requirements specifications have to be in the atomic, ‘the user shall ….’ style?
Do you prefer use cases or agile user stories?
Or are you happy with creating descriptions of user tasks and getting the developers and acceptance testers to work from these?

Use of requirements management tools

Requirement specification tools typically come with their own templates although the user can usually modify the default set of requirements attributes.
Many requirements tools also support the definition of user stories.
Some tools are designed with agile approaches in mind.
Some requirements management tools have direct links with test management and with modelling and other tools.

Use of models, simulations, prototypes and automatic code generation

Is your approach to requirements specification primarily one of creating models?
Do you build your models using tools that enable automatic generation of code and data bases?
Do you use simulation tools such as iRise?

Link with testing

Ensure early involvement of the test team. They can help develop acceptance criteria that provide an immediate method of assessing the quality of the requirements.
See also, Step 7, Requirements Verification.

Step 5 – Requirements Elicitation, Modelling and Analysis

Requirements Elicitation

Based on the strategy you determined at step 4, you are in a good position to select the most effective and relevant approaches to requirements elicitation. This may involve traditional or more agile techniques. Good requirements elicitation practices can be relevant to both approaches; try not to follow an unthinking, formulaic approach to selecting your preferred techniques.

To get an appropriate context for discovering requirements, ensure that you know which stakeholders, processes, data and business rules are involved in your project. This should normally be a subset of the context identified earlier.

Depending on the terms of reference of the project, continue with an iterative, incremental, top down approach, possibly leading to the development of user task descriptions, use cases, user stories and/or atomic level requirements as appropriate.

Elicitation proper will use a variety of techniques such as interviews and workshops where stories, scenarios, requirements and possibly ideas for solutions can be discovered.

Requirements Analysis

Requirements Analysis, is the process of examining the elicited requirements for correctness, relevance, ambiguity, conflict, testability, feasibility, and so on. Traditionally this has been a major aspect of requirements engineering.

These factors are still important in lightweight agile approaches where teams will seek to resolve issues with continual face to face meetings and workshops involving the whole team.

In all situations, I recommend taking an approach that encourages openness and high visibility.

Another aspect of our approach is to ensure that, where relevant, the architectural view is explored during requirements elicitation and analysis.

Decisions regarding the organisation of development teams and the interfaces between them should consider possible technical dependencies created by non-functional requirements as well as the more obvious connections based on functional dependencies.

Requirements Modelling

Modelling can be informal as well as formal.

Models can lead to the development of scenarios, simulations and prototypes to aid both elicitation and analysis.

There are also tools such as iRise that support making the user experience visible.

Step 6 – Requirements Validation

It is critical that prior to handing over the baselined requirements to design and development, you ensure that all the stakeholders understand and agree with what the requirements are saying. To this end we need an effective validation process.

Validation tries to ensure that all business stakeholders agree that the requirements will lead to the resolution of their problem(s).

When using an agile approach you will also need effective techniques to ensure that stakeholders understanding and agree with what is being proposed.

In theory, this should happen more easily because of the openness and inclusiveness of the approach. The challenges that can sometimes arise when working with human beings should, however, never be under estimated. This is where the business analyst’s tool kit of ‘people skills’ is invaluable.

Step 7 – Requirements Verification

There is a clear link between requirements and acceptance testing – verification.

Ensure that your requirements procedures are integrated with your verification or testing procedures from the outset, encouraging the testers to assist in the process of requirements analysis and specification. Often, the least effective person to review something is the person who created it.

Testers have a vested interest in thoroughly reviewing requirements and ensuring that they are testable.

Remember that if a requirement cannot be tested, then it’s not a requirement.

One approach associated with certain forms of agile is Test Driven Development (TDD).

Step 8 – Benefits Realisation

The benefits should have been described in the business case.

Although identification of benefits is a fairly common practice these days, it can be rare for any to check to see if the benefits were actually achieved; this is ‘benefits realisation’.

The business case should define when benefits can be expected to be realised. The process of managing benefits realisation should begin at this point.

One advantage of agile approaches that offer frequent delivery of products is that quantification of benefits and business value is easier for short term gains than when trying to predict what might happen years into the future.

For building financial cases, it is usually imperative to involve stakeholders from the Finance Department.

Keep me about informed course launches and special offers