Demystifying Use Cases

fa

Business Analyst Mentor

Demystifying use cases Solve the mystery of use cases by understanding how they can be used to address your everyday problems in business analysis

| Demystifying use cases

http://www.businessanalystmentor.com/

Initially, this paper will explore the challenges you face when considering where to invest your time and money in your professional development.

The paper will demonstrate how use case modeling is an essential tool to capture the functional requirements of an IT system.

The paper briefly describes the elements of a use case model and the key principle in use case modeling.

The remainder of the paper discusses how use case techniques can be applied to address the needs of your stakeholders, ensuring better engagement and improving your results.

Business Analyst Mentor | Demystifying use cases

The IIBA (International Institute of Business Analysis) was founded in Canada in 2003 and has over 20,000 members.

This is a sign of the growing professionalism expected of business analysts

Where should you invest effort in your professional development?

Rapid change is the order of the day for business analysts today. The IIBA (International Institute of Business Analysis) and other national professional bodies representing business analysts have emerged over the last few years.

The business analyst role is increasingly being recognized as a profession with professional accreditation such as the CBAP (Certified Business Analysis Professional) and other national standards (such as ISEB in the UK).

This is a good thing, isn’t it?

Actually, it’s a double edged sword. On the one hand, you can expect your value to your employer to be recognized. On the other, your employer expects more of you. You are expected to develop your professional skills and apply best practice.

Don’t forget the profession is still emerging. Is there consensus on what is best practice? At this stage there are many different views but some approaches are more common than others.

What does best practice look like? What techniques do professional business analysts delivering IT systems employ? What tools do they use?

This paper will explain why use case modeling is an example of best practice and demonstrate how it will benefit you.


You suffer the same pressures as other jobs with ever increasing demands to perform better

Jargon and buzz words don’t help There are plenty of buzz words and jargon about these days

- UML (Unified Modeling Language)

- Use cases

- Agile

- Lean

- PRINCE

This doesn’t help answer your underlying question:

How should I develop my professional skills?

Specifically, you need to know what techniques and skills will immediately improve the quality of your work and your productivity.

What are the problems you face today? Some of the problems you face are common in the workplace today. You are under pressure to deliver in aggressive timescales but don’t want to sacrifice quality.

You need to learn how to employ the most effective techniques to deliver the same quality in short timescales.

Use case modeling is not the answer! Given the name of this paper, you’re probably surprised. OK, it does provide some real benefits but it’s not a silver bullet. Then again, nothing is, that’s the point of silver bullets – they’re a myth!!

This is because use cases are designed to solve a common but specific type of problem in business analysis which will be described in a moment.

What is the answer? The answer is to have a variety of techniques and skills and to know when and how to employ them.

The key word here is how. It takes time and experience to master any new skill. Seeking the assistance of an experienced mentor is an astute way of gaining this expertise more quickly. You don’t have the luxury of time to experiment and learn from your own mistakes.


Your existing skills including developing relationships, clear communication and active listening are complementary skills to use case modeling

Use case modeling is one such technique that is excellent at solving a particular type of problem.

The problem is capturing the functional requirements of an IT system that will deliver the solution expected by the business stakeholders.

In order to do this, use case modeling must address several challenges:

- Introduce a shared language between the business stakeholders and the developers and testers

- Ensure it is accessible and intuitive to the business and is in no way ‘technical’

- Ensure it provides the necessary level of detail (or precision) required by the developers and testers

- Enable you to assist the business in ‘discovering’ their requirements

The use case technique provides this solid foundation. It also delivers many other benefits for the stakeholders which you will explore later in this paper.

Forget everything you know about business analysis That got your attention!! Actually, your other skills are absolutely critical.

Your ability to develop relationships with stakeholders, communicate clearly and listen actively, to name but a few, are key to your success and will help you deliver better use case models.

If you look at your stakeholders’ needs and a typical project lifecycle, you can see how use cases will help you out.

But first….


You must understand that all use cases satisfy a goal which is valuable to the actor

If you can’t see the value for the actor, you’ve probably defined a function which is only part of a use case

What is a use case model? At its simplest level, the use case model is a collection of use cases and actors. The actors describe the type of people who will use the system or other systems which interact with your solution. Each use case describes how one or more actors use the system to achieve a particular goal. It is critical that each use case describes an activity that delivers something of value to the actor.

The use case Buy product is of value to the actor Customer. This is self evident to any self-respecting consumer!

What about Search for product? Is this a use case? Why would a customer want to search for a product alone? They wouldn’t. They might Browse products as they might be researching. So Browse products and Buy products are use cases but Search for product isn’t.

The difference is that Search for products is a function. As a function, it’s a critical component of both Browse products and Buy product. But it has no independent value. A system which allows you to browse or buy products is valuable. One that allows you only to search is of no value to anyone.

Use cases that deliver value to the actor are easily understood by your business stakeholders. Your stakeholders have to work much harder to understand use cases that are, in reality, system functions as it is more difficult to see the point of the use cases.

If you make it easy for your stakeholders, they will be more engaged and you will achieve better results.

Now to the stakeholders…


What does your project manager want? Your project manager will want early estimates from the team to produce a plan and budget. This doesn’t seem unreasonable but you need to provide the developers, testers and other stakeholders (e.g. training designer) with enough analysis documentation to enable them to deliver estimates. How do you deliver this early in analysis?

You identify all of the use cases without analyzing the detail. Once you have all the use cases supply an estimate of the complexity of the use case along with the number of interfaces to other systems. This is usually enough information for the developers to provide a rough estimate. You can work out a more scientific approach, perhaps based on use case length and predicted number of alternate flows (you may not need to invest the effort of drafting a full use case but you will have to think about the complexity of each one).

You should adopt a variation on this approach to suit your organization.


Prioritize the use cases with the business at the start of the project. Don’t wait until the scope changes. (Click here for more on the MOSCOW prioritization technique)


How do you help the business decide what gives the best return on investment and where the priorities lie? How do you reflect this in your business analysis documentation? How do you do it quickly!?

Once you have identified all the use cases you prioritize the use cases at the start of the project (using the MOSCOW approach or your preferred method).

When it comes to reducing the scope later in the project, you already know which use cases should be deferred or descoped. Because each use case already has independent value to the business, it is relatively easy to prioritize the use cases. It is an almost impossible task to prioritize functions as they have no independent value to the business.

This is another reason why you must ensure that each use case is of value to the actor and is not simply a system function.

New scope (All uses cases marked ‘Must’ and ‘Should’)

Deferred use cases (All use cases marked ‘Could’)


http://en.wikipedia.org/wiki/MoSCoW_Method

http://en.wikipedia.org/wiki/MoSCoW_Method

The business sponsor may have a different name in your organization. In essence, it’s the purse holder and the ultimate decision maker who is answerable for project success or failure

Who helps you deliver? You are critically dependent on your business stakeholders to deliver a quality product. You must have quality time with your stakeholders. But they are usually busy people and either can’t commit all the time you need when you need it or don’t give you the quality time you need.

Maybe they don’t review the documentation when you ask them. Sometimes it can be a real struggle to get their input and agreement to your requirements documentation.

Perhaps some of the stakeholders genuinely struggle to understand the requirements documents. This runs the risk of missing some critical requirements which emerge later in the project when the cost of fixing them is much greater.

How do you get cooperation from your stakeholders? How do you ensure the best feedback from your stakeholders?

You must start by understanding your stakeholders’ perspectives:

What’s your point of view? All of your stakeholders have different perspectives:

The business sponsor doesn’t want to know all the fine details. They just want the big picture. They are primarily interested in the overall cost, the new capabilities introduced by this project and the impact on their business.

A high level view of the system is sufficient for them.


The use case diagram is a great tool for showing each stakeholder the slice(s) of the system that interest them

Each of the use case ovals hides a detailed use case (as shown). You don’t need to make the business sponsor aware of this detail (unless, of course, they request this detail).

Whilst the business sponsor is interested in everything at a high level, most stakeholders are only interested in their area of responsibility. They just don’t have the time to consider other areas.

You must invest the time to prepare the view of the system which is of interest to them. This allows them to focus on giving you feedback in the area where they have an interest and expertise and can give you valuable input.

The use case diagram is a great tool for slicing the system into pieces and can be used to give a stakeholder-specific view.

The marketing manager will be interested in the following diagram as their primary area of interest is the customer:

The marketing manager and the marketing administrator will both be interested in this diagram:


You can show progressively more detail of your use case model. Start with the high level use case diagram. Move to the use case brief description and end with the full use case narrative.

Consider what level of detail works best for each stakeholder

If you show stakeholders only the material that is important to them at the level of detail they require, they will be happier to invest their valuable time, you will gain some goodwill and you will get better feedback.

You must consider each stakeholder separately and decide what level of detail works best for them. More senior stakeholders want the big picture and users want the blow by blow description of how they will interact with the system because they will be most affected.

High level

Customer

Browse products

CUSINF

* * * *

More detailed

Full detail



The Marketing Administrator will actually be using the system so she is keen to see exactly how the system will operate. It is very important to her that it reflects her way of working and makes her life easier.

The final users of the system will not be interested in the fine detail of the system.

They may find the use cases hard work or difficult to visualize. Support them with prototypes that show a real world scenario with real world examples.


In summary

Use case modeling is an essential tool to have in your toolbox. However, it’s not a silver bullet and should be applied with insight and consideration of your stakeholders. It should also be used alongside other approaches, not least your existing BA skills.

You explored the problems your stakeholders suffer and you also learnt how specific use case techniques and prototyping can be applied to solve those problems.

Ask your stakeholders where they want to be involved, the level of detail that interests them and listen carefully to their answers.

Use your knowledge of the stakeholders and the relationships you have established to decide whether to present use cases alone or prototypes alongside your use cases.

If you give all the stakeholders the same bulky document, it isn’t going to get them on your side.

Go the extra mile and prepare your use case view so it suits each stakeholder’s perspective and needs.

If you keep your stakeholders happy and consider their needs, they are more likely to give you their time and attention and the quality of their input will be much greater.

When it comes time for your appraisal, who gets consulted? That’s right, your peers and stakeholders on your project.

So, when you employ these techniques, not only will you perform better and be happier with the results, your career should get a very real boost!!


Demystifying Use Cases

Documents

Transcript of Demystifying Use Cases