“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 »
Alnisa Allgood, a consulting colleague of mine, just turned me on to Belarc Advisor, a personal-use tool that does a very fast and thorough system audit of Windows machines. Unlike anti-virus/anti-spyware that I’ve used, it also tells me a lot about the system itself, and potential vulnerabilities due to the way legitimate software is configured.
CNET gave it 5 stars, which is unusual.
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 »
This post came out of a long thread on the LinkedIn IIBA Group, entitled “A development manager uttered, ‘Adding a Business Analyst simply adds an extra layer in the SDLC, which creates a gap in the development work and keeps the developers away from stakeholders.’ Is he right?”
It was a great discussion, and I wanted to summarize for anyone who faces this attitude and wants to change it.
- Don’t let the skeptic put you into defensive, fight-or-flight mode, because then they will probably respond in kind. Listen long and carefully.
- Don’t assume that a Business Analyst really is the solution, and certainly don’t try to force it.
Encourage the skeptic to tell the story of their experiences with Business Analysts. Skeptics may not always be right, but they nearly always have a point. 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!