Declan Chellar

Every project needs the perspective of Demetri Martin.

I have had discussions with colleagues about use cases (and seen discussions on LinkedIn) where it is clear that some people do not understand that there are different types of use case, so I hope the following definitions help.

Business Use Case
A technique for describing (in technology-agnostic terms) a business process which is invoked by business actors (people or external systems), often working in collaboration, in order to achieve a specific goal (or goals) that provides clearly defined business value to the actors (e.g., process a customer order).

A BUC can describe both manual steps, such as greeting a customer, as well as steps which are expected to be supported by an IT solution, such as recording customer details.

A BUC is often supported by several System Use Cases.

System Use Case
A technique for describing the interaction between a business actor (e.g., a person or external system) and the target system in order to achieve a result of clearly defined business value to the actor. A SUC will describe what the system will do for the actor but not how it will achieve it. A SUC will not describe any actions outside the actor/system interaction. A SUC is implementation-agnostic and does not make reference to screens, screen elements (e.g., buttons and drop-down lists) or screen activities (e.g., “clicking”).

A SUC is often supported by a single Technical Use Case.

A SUC is often supported by one or more UI Specifications.

One or more SUCs can be represented by a Screen Flow. Several SUCs can be represented by a Workflow.

Technical Use Case
A technique to describe, in implementation terms, how the target system will achieve what is described in the corresponding SUC, in order to provide the business value described in the SUC.

The following definitions are useful if you are involved in workflow solutions:

Work Type
A work type defines the kind of item that will be processed in a Workflow System.  A work type is represented as a work object to an end user.

Workflow
A workflow can be described as a repeatable collaboration of tasks (each of which may be represented by a System Use Case) that affect an identified piece of work (work type), across multiple roles. The workflow is governed by business rules. The flow begins with the generation of the work type and ends with the resolution of the work type.

Inexperienced analysts often confuse System Use Cases with screen flows. A poorly written SUC talks about clicking on buttons. This is not a good idea because the SUC should focus on describing what the business needs the System to do. Buttons, drop-down lists, checkboxes, etc, are all part of how the System does what it needs to do and belong in the realm of high-level design.

Moreover, when analysts write SUCs as if they were screen flows, they cause confusion because they start to talk about clicking the “Cancel” button instead of the “Confirm” button as if it were an alternate flow within the SUC, which it is not.

UI Specification
A technique for describing each required User Interface in terms of what needs to appear on the screen (data) and how the screen needs to behave. This technique describes the screen elements that are needed in conceptual terms (e.g., a widget to enable to User to select among several options), but not in concrete terms (e.g., a drop-down list). A UI Specification represents a single screen.

Screen Flow
A technique for illustrating all possible paths through the screens that support a specific set of SUCs, indicating what concrete UI elements trigger the movement from one screen to another along the path (e.g., “Submit” button).

I hope this helps.

Kind regards,

Declan Chellar

I am a great believer in facing up to reality, regardless of the pain involved. I don’t know whether it is my experience as a senior business analyst or my character or both that causes me to step in from time to time and say: “Stop! Time for a reality check!”

How many times has your manager demanded the improbable (or impossible) but expects that a “can do” attitude will turn it into a reality? This is what I call “dropping the buck”. It is not simply a case of passing the buck, but dropping it on you from a height.

All you can do in those circumstances is highlight the risks involved (and the likelihood of their occurring). For my part, I never commit to something that I do not believe I can deliver. People can interpret my attitude as negativity, but I see that as their issue and not mine.

Continue reading Reality check

Junior requirements analysts sometimes have difficulty with how to document business rules, or indeed, with recognising them in the first place. I hope this short article helps.

Some Definitions

“A rule under which an organization operates. A policy or decision that influences a process step.” (Data Warehousing Team, Georgetown University)

“A statement that defines or constrains an aspect of the business. It is intended to assert business structure, or to control or influence the behaviour of the business.” (www.brcommunity.com/faqs.php)

These two definitions say essentially the same thing. It is interesting to note that the second definition appears verbatim on several web sites.

Context

Of course, even businesses that operate without computers have rules; a market trader might have a rule that all employees wear an apron while tending the stall.

Within companies that have IT systems, there are rules that do not affect how the IT system itself operates; for example, there may be a rule that when paper form ABC123 is received, the details are always entered into the computer. One might mistakenly argue that this does affect how the IT system (henceforth referred to as the System) operates since a computer is used. However, it is up to the user to decide whether or not to obey the rule; the System cannot invoke the rule, nor does the rule affect the behaviour of the System.

In documenting an overall business process, we would of course make note of all business rules. However, when documenting a set of user-system interactions, we are only interested in rules that are invoked by the System in order to influence the System’s behaviour.

Rule or Process Step?

Even within that context there can be grey areas. One could say that every requirement is a business rule, since it has been defined by the business, and that is certainly one approach.

If your approach is to document a process, perhaps the flow of an identified piece of work, later broken down into use cases for handling that work, then structure has to be imposed in order to help us understand the business requirement.

We need to understand what triggers the process, the pre-conditions that must be in place before starting, the primary flow through it, any alternate and exception flows, the post-conditions that result from the completion of each path and the business rules that allow the System to decide which path to take.

The analyst has to consider whether the stated requirement should be documented as a business rule or as a step in a path or as a pre-condition to the process.

Continue reading What is a business rule?

I have found that people, from business SMEs to software developers, often confuse triggers and pre-conditions.

Whether you are producing a business activity model, a process model (business use case) or a system use case, both concepts are relevant and the distinction is important. It is also important to be able to explain the difference, so here we go. I’ll start with an example of a common misunderstanding.

Think of a scenario for logging on to a system. Many people assume that a pre-condition to that  scenario is that the Actor already exists in the system as a user. That assumption would be wrong, however. If you are not sure why it would be wrong, or if you disagree, pause and think about it for a moment before you read on.

Continue reading Pre-conditions

Which of the following two profiles do you think matches what a leader should be and which matches what leaders generally are in reality?

Which of these profiles do you think fits the people who made the decisions which nearly put the world through financial Armageddon?

Which do you think is more likely to get a promotion?

Hands up anyone who has been invited to a meeting, spent an hour or more listening to someone drone on (or worse, sat through Death by Powerpoint), only to wonder why you had been invited in the first place. Oh, look! All of you.

MS Outlook allows you to indicate whether each attendee is required or optional but no more than that.

So here is a suggestion: in the body of the e-mail, list all the required people and after each name, state why that person is required. This, to me, is basic business courtesy.

Hint: either you need them to contribute something or you need them to learn something. If it’s neither of those, they are not required!

Now I can hear some people saying, “I’m too busy to put all that information into a meeting invitation!”

In other words, you’d rather save yourself five minutes than save the project several man-hours? Now, that’s team thinking.

Let’s flip it on its head. You have a right to know why you are required at a meeting. If you get an invitation that doesn’t make it clear, reply and ask the organiser to make it clear. Expect the organiser to make it clear and if it is not made clear, decline the invitation. If that doesn’t provoke a response, then you weren’t really required, were you?

If declining does provoke a response, then ask again why you are required.

But after all that you find yourself in a meeting and you realise it’s a waste of your time. You aren’t learning anything and you aren’t contributing. When that happens to me, I wait for the next break and politely explain to the host that there is no point in my being there. Then I get back to work.

Takeaway:

• Your time costs your company and your customer money. People will inadvertently waste that time and money by inviting you to meetings which you do not need to attend. Make sure you are really needed at each meeting.

Kind regards,

Declan Chellar

Many of you reading this will not know that in addition to being a business analyst, I am also an aspiring writer.

On a recent business trip, I began writing a log of my journey, as it turned out to be not as straightforward as I would have liked. I had intended to publish the log here, as I imagine a lot of you would be able to relate to it.

However, the log turned into a story of sorts. I ended up weaving elements of my inbound flights to Dresden and my return trip, as well as a walk I took around the city. Most of what you are about to read is true. I hope you can tell which part is fiction!

Kind regards,

Declan Chellar

Continue reading Business trip

A visitor to my blog commented on the post “No favourites” saying that her solution to the problem of being asked multiple security questions (none of which might apply) is to use a single word as the answer to all such questions.

So no matter whether they ask what your favourite movie is, or what your least favourite infectious disease is, or who you would most like to come back as if reincarnation were possible and you were run over by split-level sheep transporter, your answer might be “Rumplestiltskin”.

As with many elegant solutions, it is very simple.

Of course, the effect is to reduce all security questions down to one:

“What is your backup password?”

That’s right, all that time trying to come up with clever questions… wasted.

I’m not convinced that asking a bunch of questions to which the user might not be able to relate (or the answers to which might change over time) is the best solution, especially if it leads users to effectively using a backup password.

It makes me wonder whether the requirement was expressed along the following lines:

When a user forgets their password and has to ask for a reminder, we need to be able to ask security questions.

A poor requirements analyst would simply document the requirement as stated, then ask what the security questions should be and hand over the requirement and the list of questions to a developer. I call such people “requirements stenographers” and they are about as useful as a tape recorder but a lot more expensive. Chances are that a developer will simply build what was asked for, rather than questioning the requriement, especially if development is being done off-shore. GIGO.

An analyst, on the other hand, always asks why and by encouraging and helping the customer to find the right words to explain why, something along the following lines might be discovered and documented:

When a user forgets their password and has to ask for a reminder, we need to confirm the identity of the user.

Thus, a good analyst drives down to the real business need and expresses that need in a way that allows the maximum flexibility in producing both business and technical solutions.

To the people who think up security questions for web sites:

I do not have a favourite actor / musician / artist. If I pick one just for the sake of it, I will not remember my choice when I have to answer the security question.

I did not have a favourite place to visit as a child.

I do not have a favourite song and even if I did, it would probably have changed by the time I have to answer the security question.

Nor do I have a favourite book, even though I have an extensive library.

I don’t remember what was my most memorable gift as a child.

Nor do I remember my first toy animal.

I don’t follow sport, so I don’t have a favourite athlete.

I have never been married, so I don’t know the first and last name of the best man at my wedding.

In fairness, I do remember the name of the first company I worked for.

While I like food, I don’t have one particular favourite and even if I did, it might change before I ever needed to use answer a security question.

As for my dream occupation, it certainly is not thinking up security questions.

What I do remember, is my password! So please stop making it mandatory to select a security question!

Kind regards,

Declan Chellar