I started doing “business analysis” before I knew there was such a thing. We called it “Getting the requirements” or “Making sense of the requirements” or (often) “Who came up with the requirements (and the schedule)?”
I read books, went to conferences, thought a lot, and tried things out. A decade later, here’s how things typically go, when the client and I jell as a team, and I do it right, and it works.
By “works,” I mean the new (usually software-enabled) business process has been running for a while, and all stakeholders (including the makers and the person who paid the bill) are saying, “I’m glad we did that. That was worth more than it cost. Let’s do another one!”
So, here’s the candidate pattern.
- A would-be sponsor comes to me with an idea—a What—and a desired (Target) cost and deadline. Their idea is often either:
- Quite tangible—a screen sketch on a napkin–or even too tangible for this stage, i.e. wireframes from marketers and designers, or
- Quite abstract, except for one thing—“We need a mobile app! Yesterday!”
- Using questions and active listening, I help my would-be sponsor back up to Who and Why? Who’s going to use the new or changed product or process? Why would they want to do that? Why would you want them to do that? (Be careful with literal “Why.” It can feel confrontational).
- I then lead an examination of possible Whats that might satisfy the Whos and Whys, from four perspectives, using another pattern, the Merry-Go-Round™ :
- User Interface (UI)
- Data / Information, and
- Rules / Constraints.
- Most often from the Rules and Data, I infer additional Whos affected by the proposed What. Often they are not clearly beneficiaries. What additional changes, either part of the What, or alongside it, are needed to make them whole?
- I then see that an Estimate of cost and timeline is prepared, independent of the Target from #1. Target-Estimate-Commitment is another pattern I’ve observed and use.
- If there’s still too much uncertainty regarding the cost and benefit of the What to proceed, I then recommend where we should “buy a vowel” (a metaphor from the decades-long American game show, “Wheel of Fortune”), typically in one or more of Team, Technology, and Requirements.
- For Team, that means actually doing a bit of the work, end to end, to help them jell and get a sense of velocity.
- For Technology, that means a Proof of Concept, especially if we’re going to bring in something new, e.g. commercial software.
- For Requirements, that means further elicitiation and analysis of those portions of one or more of UI, Function, Data, & Rules where the cost / benefit sensitivity is greatest.
- I then provide decision support for a Commitment regarding the Essentials, Value-adds, and Delighters (Kano model) of the What, helping tie those back to Whos, their goals, and the associated costs and benefits (from the Estimate, with associated ranges and probabilities). I encourage variable-scope thinking. Resources usually are more tightly constrained than scope, and those constraints need protection from the remaining uncertainty (and there’s always more uncertainty than we would like, particularly if it’s potentially a high-impact What).
I have a typical Implementation pattern too, but that’s Out of Scope for now.
That’s how Business Analysis usually goes for me. Like all potentially robust patterns, it’s come from observation, not prescription. I didn’t read or decide, “This Is How It Goes.” Rather, I’ve observed, “This Is How It Usually Goes When It Works Well.”
I hope this candidate pattern works well for you, too. I believe it’s only a real pattern if it’s worked three or more times for three or more people. Please share your stories!
I’ll add two pictures when I get the time. That might make the pattern easier to see.
London Transport passengers are exhorted to “Mind the Gap” between the platform and the train. The gap’s dangerous.
Likewise, I exhort business analysts to “Mind the Gap” between the Stated Requirements and the Implied Requirements. If you don’t, you’ve doomed your team to scope creep (more like scope avalanche) and probably a lot of budget and schedule pressure, and it won’t be the sponsor’s fault.
Minding the Gap—getting the implied requirements close enough—is the difference between a requirements order-taker and a Business Analyst.
So, how do you come up with requirements that no one’s stating?
I got the idea from Doug Rosenberg’s & Kendall Scott’s “Robustness Analysis” and Ellen Gottesdiener’s “Multi-Modeling.” I invented the Requirements Merry-Go-Round© as a way to explain it to others. I’ve since found it useful for the other things I’ve been writing about.
The original Merry-Go-Round© had only two horses—Function and Data.
You start with Function—say Use Cases or User Stories. Imagine some (very simplified) software to help pilots with flight planning and navigation. Functional requirement elicitation turns up:
- As a Pilot, I can select my departure, arrival, and alternate airports when preparing my flight plan.
- As a Pilot, I can enter the departure runway when I’m given my departure clearance.
- As a Pilot, I can enter the arrival approach to the arrival airport, and the assigned runway for landing at the arrival airport, when I’m assigned them by the air traffic controller.
- As a Pilot, I can select Voice Mode and the software will read me the waypoints, altitudes, and speeds for approach and landing.
Now, you head off to your lonely analyst’s garret (if you’re just learning) or let your Subject-Matter Experts (SMEs) take a break (if you’re a rock star) and head around to Data.
Everyone who makes software learns to look at the functional requirements for nouns: Airport, Flight Plan, Departure Runway, Arrival Approach, and Arrival Runway (I left out a few to keep it simpler). Then, sketch a logical data model. Then, re-convene your SMEs for some more elicitation.
The crafty BA will have noticed the sloppy use of sometimes “enter,” sometimes “select,” and found out that there are lists of Airports, and each Airport has a list of Runways, and each Runway has multiple Approaches.
Then, for each entity on the data model, ask three simple questions:
- Where do these data come from?
- What are all the possible uses for these data, and by whom?
- When and how are these data disposed of, and by whom?
You’re checking for CRUD—Create, Read, Update, and Delete. Data have to come from somewhere, and be read by someone.
The Pilot enters the Flight Plan. That’s one of the stated requirements. And s/he selects Airports, Runways, and Approaches. This we know.
But where do the lists of Airports, Runways, and Approaches come from?
“Oh, I guess we’ll need screens to enter and edit them.” Inspired by Ruby on Rails, modern application frameworks in many programming languages, and modern programmer tools like Microsoft’s Visual Studio now have “scaffolding;” when you create a data entity, it just creates plain-vanilla versions of these screens for you.
“We get them in a file from the government.” I’ll leave it to you to imagine what you would need to find out next!
“That’s a good question. I was hoping you could tell me. I’m just the marketing guy—I’ve been going around to air shows, talking to pilots about what they would like our software to do.” Someone, maybe you, now has a research project that could invalidate the feasibility of the whole project. Disaster averted.
To summarize, here’s how to Mind The Gap and find the requirements that no one’s mentioned:
- Elicit the functional requirements—the ones that are driving the project
- Infer a logical data model from the nouns in the functional requirements
- Infer the implied functional requirements from the entities in the logical data model using the CRUD check (Create, Read, Update, Delete
You’re not done, though. Your implied functional requirements are just a first draft for another round of elicitation. Involve additional subject-matter experts (SMEs) and expect a flow of additional information. If the implied requirements touch another part of the organization, you may have a new senior stakeholder. Get the sponsor’s help in developing that relationship and working out a potential change in the business requirements as well.
You still might not get a bonus though. Disaster averted is disaster disbelieved.
Until I started writing this series, the Requirements Merry-Go-Round© I drew on white boards had only User Interface, Function, and Data.
I added Business Rules because I know they’re important. But I’ve been putting off writing about them because I don’t know as much about the tools for eliciting, analyzing, and describing them as I feel I should. But that doesn’t mean I know nothing, so here are some simple tools that have worked well for me as I’ve developed requirements for smaller systems.
The Sponsor and primary Subject-Matter Experts (SMEs) are not likely to board the Merry-Go-Round at Business Rules, unless the system itself is about some kind of compliance. So you, the business analyst, have to ask the right questions to elicit them (draw them out). They’re often found near Data and Function, so ask these questions when working with those perspectives.
What exactly do people here mean when they say … ?
Read more of this article »
“You can get on anywhere you like, but you have to go around at least twice.”
So far I’ve been emphasizing where to get on the Requirements Merry-Go-Round©. Start with Function if it’s up to you, but if the Subject-Matter Experts (SMEs) you’re working with want to get on at Data or User Interface, let them.
(I’ll come back to Business Rules in a future post because I need to find some misplaced material from the last WI BADD® first.)
But the first trip around is just the beginning. Like any other kind of research—scientific, historical, journalistic—requirements work has two main activities, which the BABOK® calls Elicitation and Analysis. Elicitation is about sources. You’ve read about how to help your subject-matter experts (SMEs) talk about Function, Data, and User Interface, and how to use one to get them talking about the others. That’s Elicitation.
Analysis happens when you go back to your lonely garret and try to make sense of it all. It’s the second and third trip around the Merry-Go-Round. On the second trip, I “freeze-dry” everything, by transcribing and annotating my source material. This sounds fancy but it isn’t. Read more of this article »
Function is where you, the business analyst, want to start. Sometimes technically-minded Subject Matter Experts (SMEs) want to start at Data. But most often, especially if the software is customer-facing, your sponsors and SMEs will want to start with the User Interface. Marketing and design people will invariably start there (the really good ones will have developed Personas first). You may be bowled over by their enthusiasm and the amount of work they’ve already done. But, to quote Admiral Ackbar, “It’s a trap!” Read more of this article »
As a refresher, here’s the Requirements Merry-Go-Round©.
You can get on anywhere you like, but you have to go around at least twice. (I’ve double-ended the arrows since last week, because writing these has caused me to see that I change directions on the Merry-Go-Round a lot. No metaphor is perfect).
Most of the time, your sponsor or subject-matter expert (SME) will board at Function, because “being able to do things” is what the software is for. But sometimes, especially when enhancing or replacing an existing system, people will instead focus on all of the interesting things that are stored in the system—things I’ll loosely call “Data.”
I say “loosely” because the word “Data” can cause people to think too narrowly. It could be a document, a scan of a document, or an audio file of someone reading the document—you get the idea. So I usually use a word like Information, or even “What the system helps people work with.”
Modeling to talk about and describe Data
As with Function and its Use Cases and User Stories, the software profession has developed several ways to talk about Data. There are two main ones, Entity-Relationship (E-R) Diagrams and Class Diagrams (from UML, the Unified Modeling Language). Because these are also used by developers to talk about relational database design and object-oriented software design respectively, they have some very precise terminology and notation. Don’t go there when working with Sponsors or even SMEs (unless they’re pretty technical), and even then, try to stay out of the weeds.
One of my BA heroes, Ellen Gottesdiener, says, “You model requirements to facilitate communication.” Communication is like a freeway. When you overload it, it doesn’t just keep running at maximum capacity. It grinds to a complete halt.
The main things to model are
- Clumps of tightly related information, and
- The relationships between the clumps.
Precise definitions aren’t necessary, and can even get in the way at first.
Along with nearly everyone else, I use a boxes and lines. You can write attributes inside the box, label the relationships, and put some kind of markers on the relationship next to the boxes to indicate required, optional, and quantity.
UMLers like their numbers and asterisks and ERers like their crowsfeet. But what do Sponsors and SMEs like? Whatever you use, check that they understand. The best sign is when the SME corrects you. “There always has to be a Parent. Shouldn’t that be a one, not a zero?” That means you’re still communicating. You can tighten the lug nuts on the wheels of the truck later. The goal now is not to miss the fact that it’s pulling a trailer.
Eliciting Data from Function
How you talk about Data depends on where you got on the Merry-Go-Round.
If you started with Function, every BA knows to look at the nouns in the Function descriptions. In user-story style,
“A student completes an application to the program online. Students must provide information about at least one parent, because school policy requires a signed waiver from a parent or guardian, and the program needs a contact person on file in case of emergency.”
This follows the general,
“As a <role>, I can <do action> because <reason>” form of a user story, but in the way a subject matter expert might write it.
The initial data model might look like this:
The questions you ask are key. I might ask:
BA: Are there any other reasons why we need this parent/guardian information?
SME: “They also need someone to contact if the fees haven’t been paid.”
Huh. I just uncovered another User Story called “Someone Pays Student’s Fees.” If it’s not already on the list, I add it. It’s undoubtedly dragging more Data behind it. This is Merry-Go-Round thinking in action.
BA: Do the waiver person and the emergency-contact-person and the fee-paying person need to be the same person?
SME: “No, but they usually are.”
I would keep asking, next about adults who have more than one student in the program, but for this post, let’s move on.
Eliciting Data as the starting point
If you’re starting with Data because the first SME you talk to helped build the old system, they might even have a data model to show you. “Each Student has a one-to-many relationship with Parent.” Start a new model, though, like the one above.
Again, the questions are key. You use the model as a subject of conversation, and ideally you both add to it.
BA: Are there problems with this?
SME: “Yes, even though the table’s called Parent, they’re not always Parents. Sometimes they’re step-parents, or sometimes they’re legal guardians.”
BA: Does that matter?
SME: “Yes, school policy requires that there be a legal relationship between students and adults, for privacy and legal reasons.”
Here’s where more Merry-Go-Round thinking comes into play. If you’re thinking about requirements sequentially,
you might not pick up on that word “policy” as a Rule to talk about and understand, now. “That comes later,” or worse yet, that might be someone else’s interview. But ride around the Merry-Go-Round in your head and ask about that policy!
BA: Please tell me more about these privacy and legal reasons.
SME: “Well, I think it’s about the waiver form. Only a parent or legal guardian can sign one. You’ll have to talk to the Legal Department.”
BA: Who in Legal would be good to talk to about this?
SME: “Well, when we were sued that one time, Sally was over here wanting to know what we had on file and when it was entered.”
If Sally wasn’t on your list of people to talk to in Legal (if the plan even called for that), she’s on it now!
Often I’ll draw the Merry-Go-Round to show how I’m thinking. It often surfaces additional information.
SME: “Oh, now that I see that, another problem with the present system has to do with the fees. We record who pays the fees in a Payor table, and then things get out of whack because someone changes the Payor address and not the Parent/Guardian one, and then Development goes to do a mailing and they want an address list…”
Maybe I’m out of time or this SME doesn’t know anything more, but like someone clearing a mine field, I put a marker on the ones I suspect but didn’t confirm and remove or detonate. I’ve just heard about Fees and Payors and a stakeholder called Development and a mailing list.
More Merry-Go-Round thinking
Ellen Gottesdiener calls this type of merry-go-round thinking “Multi-Modeling.” You use one model to help with elicitation for the others.
Just like the nouns in Use Cases or User Stories often surface Data, the “because” clause often surfaces a policy or a rule. Don’t wait. Start that model now, visually, so you can get the SME thinking about it, too. (They can’t see what you’re writing in your notebook).
Likewise, when talking Data, ask your SME, “What are these data used for?” and “Where do they come from?” and “What problems arise because these data are stored like this?” It seems that most people like to talk about The Great Mailing-List Debacle of 2007. That often leads you to Rules and Functions—not all of them—but that doesn’t matter, because you’re going to go around the Merry-Go-Round at least twice, remember?
We, the people doing Business Analysis, and our Sponsor or Subject-Matter Experts (SMEs), will most frequently board the Requirements Merry-Go-Round© at Function. Why? Because it’s the best place to start if they don’t have a preference. And often their heads are there already, and they start the conversation with,
“I need it to do X.”
What we, with the BA hat, say next depends on who we’re supporting and what they’re trying to decide (Sponsor) or do (Developers).
Whom are we serving?
Sponsors must decide whether to fund this project or that, or prioritize this feature over that. They need an estimate of what each option is going to cost, and how it will help make money, save money, or keep them out of trouble with their boss or the authorities. This is about business requirements, policies, etc. They probably know. We just need to help them get there, by asking a purpose question, like “Why does it need to do X?”
Developers must implement software that does X correctly. They need to know the steps and rules for doing X using software. The subject matter experts certainly how X is done now and are usually delighted to tell us. We just need to help them describe all of the nooks and crannies, and then reconcile the different stories of how to do X with each other, while keeping current (X) and future (X’) states separate.
(I’ll have more to say about how things change whether we’re supporting Sponsors or Developers in a later post).
How do we talk about and describe Function?
This is not a new problem.
- We’ve had to talk about how to do X, and record it so we don’t forget, since the first time someone wrote software for someone else to use.
- And we’ve had to talk about why we need to do X and how much it will cost, since the first time someone decided to pay someone to write software for someone else.
So we have some proven-effective models for talking about and remembering Function: Use Cases and User Stories.
I’m assuming you already know something about Use Cases and User Stories. My purpose is to help you fit them together with the rest of the Requirements Merry-Go-Round©, User Interface, Data, and Rules, and provide some practical tips.
If you want to become a Use Case master, I highly recommend “Writing Effective Use Cases,” by Alistair Cockburn (CO-burn). You’ll learn how to work on different levels, analogous to the BABOK®’s Business, Stakeholder, and Solution. You’ll also learn how you can vary the depth of detail in your use cases to match the needs of the people performing the activities you’re supporting.
If you’re specifically working with User Stories, I’d turn to “User Stories Applied for Agile Software Development,” by Mike Cohn.
How do we elicit Function?
Especially if we are supporting Sponsor decisions, before a project is approved and funded, I highly recommend learning how to facilitate workshops. Ellen Gottesdiener literally wrote the book, “Requirements by Collaboration: Workshops for Defining needs.” (Ellen’s discussion of multi-modeling—using one model to check another—was one of two sources for the Requirements Merry-Go-Round© concept. I’ll introduce the other in the next week or two, when writing about Data).
Workshops are vital when perspectives, goals, and knowledge are diverse, dispersed, but interdependent in non-obvious ways. Eliciting business and first-draft stakeholder requirements for a system that will span functional boundaries in an organization is a classic case.
When supporting SME-to-developer communication, less structured interviews are fine, although I still prefer to interview with groups of 2-3 rather than individuals, and I always make sure to have visual modeling tools (index cards, sticky notes, markers, whiteboard, digital camera) available. The more they write and draw, and the less we write and draw, the better.
Use Cases and User Stories when transitioning to Agile
When talking to Use Case people who are transitioning to an Agile method, remove the “forget everything you ever knew” fear by describing User Stories as informal, low detail Use Cases, with the details to be worked out by the SMEs and developers, with the support of a BA with agile methods experience the first few times through. It’s not quite true that User Stories are a kind of Use Case (Cohn explains how they’re not) but people will pick that up better by example than by lecture.
The System Shall…
We will probably also encounter one-sentence “The system shall” requirements, written according to the IEEE 830-1998 Standard or some local mutation thereof. For a variety of reasons, which Cohn’s book gets into, these are very hard to work with, at least for Sponsors, SMEs, and Developers. Maybe they work well in other types of engineering, or in litigation.
If done well, they will be more or less grouped by something, often by function. More often, they’re just concatenated streams of consciousness with stilted grammar, and we, the wearers of the BA hat, will have to cut them up, organize them, cross-validate them, and organize them into groups corresponding to Function, Data, User Interface, and Rules, at the appropriate level (Business, Stakeholder, Solution). Then we will have something that the humans on our teams will find easier to work with.
If these one-liners are just how people are used to expressing their software needs, don’t fight it. When they see them transformed into Use Cases or User Stories, they usually heave a sigh of relief, particularly if they know they will have to do this again.
But if “The system shalls” are part of a contract (lucky us), we may also have to maintain traceability. I just use the numbering scheme they came with. If they are an un-numbered list in a Request for Proposals (RFP), I number them, in the order provided, and trace to that.
But what about this Merry-Go-Round?
If you’re wondering, “Isn’t he just writing about the same linear
process he said not to use last week?”
Thanks for reading, and I “salute your astute.”
The roundness starts next week (or the week after) when I write about Data, and cross-validating Data and Function to find gaps. I also have to write about the difference between Sponsor support and Developer support, and about the principle of diminishing returns. This might stretch beyond the customary four weeks!
The Requirements Merry-Go-Round© is one of those pictures that I started drawing on whiteboards before I gave it much thought.
I found myself drawing this picture when:
- I was explaining to software project sponsors and subject-matter experts about how the development process would start, or
- I was training people how to communicate with each other about what we wanted to make a computer do, i.e. how to do Business Analysis.
Before the Merry-Go-Round, my mental model of the requirements process looked like this:
I ran into two problems when trying to do requirements this way:
- People sometimes refused to start at the beginning, and
- The resulting requirements turned out to have a lot of gaps, leading to cost and schedule overruns and “death march” projects.
I would interview someone from Marketing, and they wanted to draw (or already had drawn) screens. Web designers always wanted to start with screens, or get there as soon as possible.
Then I would interview a subject-matter expert from Operations, and as often as not they wanted to talk about data and maybe functions, or rules. (I’ve recently added the rules). But if there was an old system, they would show me screens.
Now, it’s both rude and ineffective to make people communicate my way, so I learned to let them lead and talk about the element they wanted to. If it’s screens for them, we talk about screens. I infer what I can about functions and data. Then, as the interview goes on, I start asking questions about the other elements. “What else do you do from this screen?” “What information does the system remember when you save this screen.” (Say “information,” not “data.” It’s less likely to put people off. For the same reason, I usually say screen, or form, or report and not user interface unless they’re already saying user interface).
To explain why I am asking about these other things, I draw what I started calling the Requirements Merry-Go-Round©:
I explain it like this:
“We need to understand all these things to make the software, so that’s why I’m asking about them. We can get on the merry-go-round wherever you want, but we have to ride all the way around at least twice to really understand this project.”
Over the next few weeks, I’ll write about how I help people talk about each element, and finish with how I use the Requirements Merry-Go-Round© concept to detect and fill gaps, early and quickly.