This website or its third-party tools use cookies which are necessary to its functioning and required to improve your experience. We do not use cookies to track site visitors or to support advertising and marketing. By clicking the 'I accept' button, you agree to allow the site to use, collect and/or store essential cookies. See our privacy policy: Read more
We use cookies only to support functions that are essential to the operation of this site. If you wish to access this site, you need to consent to their use. If you are agreeable to this, you may go back to agree to the use of cookies.
I accept
Deny cookies Go Back

Privacy policy

Capiro recognises the importance of your privacy. We are concerned to protect all personal data that we obtain from you in the course of operating our business.

This privacy policy identifies what personal data we collect, why we collect it, where it is stored, what we do with it and how long we store it.

IMPORTANT – We use cookies only to support essential functions of the website. We do not use cookies for tracking visitors to the site, or to support advertising.

By using our website and purchasing our training courses you agree to the use of the data that we collect as defined in this Privacy Policy.

We may update this policy as necessary, e.g.

  • To comply with changes in the law.
  • To reflect changes in the services and products that we offer.
  • If we start to collect any personal data other than that described in this policy.
  • If we store data in other locations to those described in this policy.
  • If we start to process the data differently to what is described in this policy.

Capiro Ltd. is registered with the UK Information Commissioner’s Office.

Information about the data we collect

When do we collect personal data?

We collect personal data about you in the following circumstances:

  • When you subscribe to be kept informed about events, changes and additions to our range of products and services.
  • When you purchase a product or service from us.
  • When you email us or send us a contact form.

What data do we collect?

Subscribing to be kept informed about upcoming courses

  • Your email address.

You may cancel your subscriptions or memberships at any time, either by clicking ‘unsubscribe’ at the footer of emails we send you or by notifying us, e.g. by sending us a contact form.

Completing a contact form

  • To submit a contact form to us, you will need to provide your email address, first name and family name. This allows us to address you in a polite and respectful manner.
  • When completing a contact form, you may optionally add your company name and a phone number.

Purchasing a course

When purchasing an online course from us, you are asked to provide:

  • First and last name
  • Postal address
  • Phone number

Optionally, you may supply your company name

What do we use your data for?

We use the personal data you share with us to:

  • Provide the products or services that you request.
  • Provide help and guidance whilst you are using that product or service.
  • Answer your questions and communicate with you about your member account or transactions with us.

Where is your data stored?

Our web site is hosted by the company, Rainmaker Data Services (RMDS), which is based in the United States of America.

Therefore, when you submit data to us, e.g. by completing and submitting a form on our website, you are transferring this data into the USA and in using our services you consent to such transfer.

How long do we retain your data?

Legal constraints

If you purchase a product from Capiro, we will hold the data in accordance with UK law, particularly legislation related to taxation.

Subscriptions to a mailing list

Normally we retain data associated with subscriptions until we receive a request from you to unsubscribe from a mailing list.

We will periodically review our list of subscribers and members. If your membership appears to be inactive, we may contact you to see if you still want your information to be held by us. If you do not, we will delete it.

Other

We would normally retain information that you communicate to us by email or by submitting a contact form for only as long as it is useful to dealing with the matter that you raise. We may retain specific information if it will help us to provide a better and more personalised service to you.

Who do we share your information with?

The information we collect about you is not shared with or sold to any other organisation.

Online payments for our products and services are made exclusively by you via Stripe or PayPal. All such transactions are therefore strictly between you and Stripe or PayPal.

We use Google Analytics to help us analyse our web traffic.

Your right to see what data we store about you.

You have a right in law to see the information that we hold about you.

If you are a subscriber to an email list, the only information that we hold is your email address and possibly your first name and/or family name, as specified by you. You may unsubscribe from a list at any time.

If you purchase a course from you, a member account is set up automatically; the system will recognise you as a ‘member’. The details of your member account are shown on your ‘profile’. You may view and update your profile, online, at any time. You can also access your profile to change your password.

You may let us know if you want your member account to be deleted.

Additional comments

If you would like to comment on our privacy policy, or request additional information about it, please submit a contact form.

Go Back

Capiro Business analysis training uk

Online e-training

  • Home
  • Business analysis
    • About business analysis
    • BA skills
    • Learning BA skills
    • Self study for BA qualifications
  • Courses
    • Shop for courses
    • Business Analysis course previews
    • My courses
    • Free training for business analysts
    • Guides to Success – FAQ
    • E-learning examples
  • Blog
  • About
    • About Capiro
    • Clients
    • Contact

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

Topics and key questions for interview
Topics and key questions for interview

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.

Planning 3The 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

Planning 2

Eight steps to requirements success

Picture of 8 stepping stones through a sea at sunset. The stones represent 8 steps to requirements success

The importance of requirements

Whichever approach you take to running a change project, discovering and managing requirements is key to success. This article identifies eight steps that can apply to any approach, from waterfall to agile.

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 the 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.

You may also be interested in this article relating to setting and achieving goals.

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 when 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 developed 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 the 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. These can be defined in the 'terms of reference' (TORs) for the project.

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.

Requirements Consultancy

See details of Capiro’s requirements consultancy services.

Keep me about informed course launches and special offers

Product objectives

If you don’t have any product objectives, you’re not going to achieve them

HiRes As part of the project setup, the key stakeholders must agree on the objectives for the product or service to be created. Product objectives clarify the value to be gained from the project. This value statement should support, directly or indirectly, the organisation’s strategic objectives.

The business case for the project must clearly define the product goals and objectives. These should relate to the problem that will be solved by the product or service.

Project and product objectives

We can usefully separate product goals from project objectives. Project objectives identify the,

  • Product to be created
  • Constraints such as budget and timescale

Project and product objectives feature in the terms of reference for the project. Clear product objectives can help to minimise the scope of the project. Reducing the scope increases the chances of project success.

Stakeholders

In establishing product objectives at any level it is essential to get the viewpoints of key stakeholders. The skill of the facilitating business analyst or consultant is not only to obtain these individually but to obtain a consensus of opinion. This may well involve considerable negotiation skills on their part.

Discovering the objectives

We can establish the product objectives with interviews and facilitated workshops that involve the organisation’s executive and senior management. This is the point at which conflicts need to be identified. A  team effort to achieve an agreed and consistent set of objectives will be repaid many times over. On the other hand, failure to agree on objectives at this level is a guaranteed way of having a troubled project. If the key stakeholders cannot agree on what is to be built then the project is in trouble.

Goal analysis – who does it?

Goal analysis is often a role for the more senior and experienced business analysts and architects. The analyst will draw out the viewpoints of the stakeholders, highlighting areas of agreement and discord. A skilled negotiator can help stakeholders to avoid backing themselves into corners from which they cannot extricate themselves without losing face. It’s often stated that business analysts must identify conflicting requirements; the optimal time to deal with conflicts is right up front, with goals and objectives.

Goals and requirements

In his book, Requirements Styles and Techniques, Soren Lauesen refers to product goals as ‘goal level’ requirements. They may also be considered as ‘business’ requirements. For a single goal level requirement, there will typically be multiple,

  • User requirements (Lauesen calls these, ‘domain level requirements’)
  • Functional requirements (Lauesen calls these, ‘product level requirements’)

Testability of product objectives

Like other levels of requirements, goals must be written in such a way that they are testable, although typically the testing will not be possible until the products created by the project have been delivered to the business.

Never lose sight of the product objectives

We must ensure that the goals are kept permanently in view. It is important that all members of the project understand what the goals are. A change to the goals is likely to impact many aspects of work already undertaken

  • « Previous Page
  • 1
  • 2
  • 3

Guide to Success training – Features and Benefits

Be among the first to hear about a new course.

Grab it at the early bird price.

Keep informed about special launch prices

Recent Posts

  • Business Data Architecture
  • What is business analysis?
  • What is a non functional requirement?

Search Form

© 2022 Capiro Ltd - Members: Log in

Privacy Policy

×