Creating BA Competency

As part of our Live from BAWorld: Boston series, I just heard a talk from Karen McKay at Doreen Evans Associates (DEA). She discussed building a BA competency in your organization. Her talk was focused on the high-level need for such a model and what the components of it are. I think a next level of discussion that would be interesting is tactics you could use to create one yourself - which specific tools and tactics work.

At DEA, they use a model that is very similar to the CMM, with five levels of competency: initial, repeatable, defined, managed, optimized and have helped build this at a handful of organizations. We do something similar to build BA maturity in organizations, but I haven't actually seen it laid out next to the CMM model quite like this. At the requirements process level, they use requirements models which I applaud - context diagrams, org charts, use cases, process flows, DFDs, etc. This talk further validated what I'm seeing in industry - alas, models are really the current state now. So if you write your requirements in plain old text, I fear that is really seen as out-of-date "technology" and you need to look at visualization techniques.

Something interesting that she did with her slides was to describe parts of their competency models using requirements models. For example, there is a swimlane diagram to show the BA role - clearly showing how BA activities relate to IT and PM functions. I haven't done much of this recently and think it's a great idea that I will use.

Anyway, this is a topic that I'm definitely interested in as we try to help customers build their competency around requirements as well. It seems like organizations are really recognizing the value of BAs now!

Live from BAWorld Boston

This week I find myself at Project Summit & BAWorld: Boston for about a day and a half.

This morning I presented our talk, "If you Build It, Will They Use It? Leveraging Business Objectives to Deliver Successful Projects". One thing I like about the BAWorld symposiums is that they make the slides available electronically to everyone, they are reviewed by a committee before you can present them, and they insist that the speakers provide learning objectives so you know what you are getting. So to that point, here are the learning objectives for my discussion:

• Understand how Business Objectives are vital to businesses
• Understand how to elicit and write good Business Objectives
• Understand how to use Business Objectives to assess measurable value of individual features

I had a blast with the audience here - great participation in some of my games (yes, we do them in presentations, not just our training classes!).

If you haven't been to one of these conferences, I recommend it if you are a practitioner doing Business Analysis, Requirements Engineering, or Product Management. Everyone else here is also practicing the "art" of BA and looking for new tips and techniques to take back to their organizations.

Anyway, I attended a few other talks of interest today that I'll blog about shortly!

Do You really Believe in What you Do?

I have a question for all of you BA/ RE/PDM people in the world. Do you really believe in what you do for a living, or is it just a job? My wife needs a new mode of transportation. Her current ride is 12 years old, has more than 240K miles on it and is beginning to require more repair than I’ve got time. So now we’re out looking at all the different vehicle options. I have to say that that I find this very frustrating because she really has no idea of what she wants. We get home from our first shopping trip and she can see that I am obviously put out by all of the "I don't know" answers she gave me while trying to find her a car. She says, “So I guess you don't want to go look again in the morning.”

Ding! The light bulb went off.

I told her we needed to figure out what our requirements were before I set foot on another car lot.

The next morning we set down with pen in hand and I started asking her what was important to her -What her needs were. We created a nice long list of items. Next, we looked at each item on the list to determine what need each of the items addressed. Finally, we prioritized the wants from the needs. We talked about number of passengers, baby seat mounts, fuel efficiency, heated seats, number, size and placement of cup holders, as well as just about anything else you can imagine. I now have a more defined idea of what she needs and what she wants in her next car, but more importantly, so does she. After all of the headache, I wondered why I did not complete the exercise sooner. This is what I do for a living. I help customers define their needs, identify requirements, separate wants from needs and prioritize it all.

If it works everyday for the job, why not use it at home? It’s hard to beat having a job that’s so helpful in so many situations.

When was the last time you found your BA/RE work to be helpful outside of work?

How to Select Software Requirements Training (It's not just about the BABOK)

So it’s time for your organization to select requirements training for your business analysts, product managers, project managers, even developers. Here are some suggestions on what to look for!

The obvious things to look for:

• Course Agenda – make sure the agenda is published and the topics seem relevant to your group. For example, if you do not use RUP, do not select a RUP-based class. If your team is good at the basics, consider a more advanced class, for example focusing on elicitation.


• Training Costs – these are relatively consistent across courses, but typically you can expect to pay anywhere from 600-1500 per day per student.


• Time Commitment – make sure you sign up for a course you are willing to commit to. Typically industry courses are run in full or half day increments. Make sure your people know it’s a priority to attend once you’ve signed up. Also, I prefer courses that are done in smaller increments, for example a series of 4 classes at 2 hours each, because the students can take time to think about and practice the concepts between classes. This resembles the teaching method used in universities, but it is very hard to find in industry.

The less obvious but more important:

• An Engaging Experience – the materials used during course must be engaging, as to not bore the students to sleep. As a rule of thumb, most learning happens in practice not lecture, so look for a course that has at least 50% of the time doing practice exercises.


• Competent Instructors – be sure that the instructors will be interesting to listen to. This may be tough to evaluate, but you could try calling them ahead of time. In addition, they need to be credible. My personal favorite is to find instructors who are also practitioners, having actually done the thing they are teaching. They will use more real-life stories in their teaching, which help put the lecture in context.


• Your Expectations - Be realistic yourself about what you will get out of the training and what you won’t. Referring back to the Kirkpatrick model, most training only measures levels 1 and 2, satisfaction and immediate recall of the material respectively. If you are looking for level 3 and 4, behavior change and impact to the organization, then recognize that most training alone will not give you those, and certainly is not likely to measure that they did happen. Typically mentoring in addition to or instead of training will help you get to level 3 and 4 in the organization.

Sadly, I have seen disappointed students coming out of all kinds of training experiences, and typically it is because their expectations were wrong going in.

How to Prepare for Software Requirements Sessions with Your Users - Tip 4

Our final suggestion on this topic is to Sit With Your Users.

If your users are extremely busy, and the project involves changes to or replacement of an existing solution, then turn the challenge into an advantage. Sit beside the users while they perform their job tasks.

Typically this is a good way to elicit requirements because users cannot always articulate their needs if they are used to completing tasks without thinking about them. This technique will require follow-up meetings with the users after, but then those meetings can be prepared for as above, with intelligent questions based on the observations, thereby shortening the time that users are away from their work.

Let's recap, we've now offered the following suggestions to prepare for requirements sessions with users:

1. Organize Your Time
2. Prepare Your Requirements Models In Advance
3. Prepare Your Elicitation Questions in Advance
4. Sit With Your Users

There are many ways in which requirements analysts can intelligently prepare for requirements sessions with users. Typically a mix of the above suggestions will work well on any project. These tips will help the analyst and users get the most value out of the available time.

By the way, you can download all of these tips in a whitepaper that I've written. Enjoy!

How to Prepare for Requirements Sessions with Your Users - Tip 3

We have now discussed the need to organize your time and prepare models in advance of the sessions.

Today we suggest you Prepare Your Elicitation Questions in Advance

One of the key steps to take prior to a stakeholder meeting is to prepare a list of questions to be asked during the meeting. These questions might be created based upon past experiences or recent meetings with the user. If the analysts know the users, the organization, or the types of issues they face, that knowledge should lead to obvious questions. If the analyst has met with the user already, new questions should be created based upon those original meetings, lessons learned and new issues identified. Also, if drafted models exist, those most certainly should prompt questions.

There are some stock questions that you can use as a guide to requirements gathering sessions. Keep in mind, though, each project will need its own unique questions, and some of these questions are likely not appropriate.

How to Identify Actors for Software Requirements

Here are some suggested questions to ask to identify the actors of the system. These questions are in a guide that we've design to keep on your desk. Download it here.

• Who uses the system?
• Who installs the system?
• Who trains people to use the system?
• Who fixes the system?
• Who starts up the system, who shuts it down?
• Who maintains the system?
• Who creates, updates, deletes information in the system?
• What other systems interface with the system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically at a predetermined time?

How to Identify Use Cases

The following suggested questions can be used to identify the list of use cases or system functionality.

• What functions will the actor want from the system?
• Does the system store information?
• Do the actors need to create, update, or delete information?
• Does the system need to notify an actor about changes in an internal state?
• Are there any external events the system must know about?
• What is the actor’s overall job?
• What problems has the actor had in the past?
• What steps are manual today?

How to Identify Alternative Courses

In order to identify alternative courses or exception paths, these questions should be asked at every step of a use case main course.

• Is there some other action that can be chosen?
• If X does not happen, then what should happen?
• What if the actor cancels an operation (e.g., closes a window)?
• What if the actor provides incomplete information?
• What might go wrong at this step?
• What if part of the system goes down or is unavailable?
• Are there any events (or interrupts) that might occur at any time during the use case?

Are you ready for the last part in our series? It's an oldie, but a goodie!

How to Prepare for Software Requirements Sessions with Your Users - Tip 2

Last time we talked about organizing your time.

Today's suggestion: Prepare Your Requirements Models In Advance

Prepare draft requirements models in advance of the meeting. The reality is that good requirements analysts do in fact know quite a bit about the business processes and requirements. There is a misconception that they should remain unbiased; however, these individuals become experts in the systems they are capturing requirements for and that expertise should be utilized to its full advantage.

As an example, if you are going to cover a topic with a user about how he or she does a task, then you can try to come up with the obvious use cases in advance. You can then take it one step further and actually try to write the header information and normal course for the use cases. Similarly, you may find it valuable to draft state diagrams, where you capture the states and transitions that are obvious and highlight the unknown ones for completion in the meeting. Virtually all requirements models can be pre-drafted if you know a little bit about the business.

In doing these models ahead of time, you will find yourself jotting down lots of questions in the margins, like "What really happens at this step?" or "Should they do X instead of Y?". Even if you throw away the draft model because it was all wrong (which rarely happens), there is still a value from the time investment because you came up with a list of detailed questions. Essentially this is a brainstorming tool for you.

Starting from a blank slate can seem like a daunting task, so once you have draft models, in the meetings with users, you can use these models to work from. Similarly to the authoring experience, reviewing the models will spur questions in the reader’s mind. Therefore they make an excellent tool with which to facilitate a user meeting.

See another great post on how to choose a requirements model.

Come back for part 3 next!

How to Prepare for Requirements Sessions with Your Users - Tip 1

This is the first part of a four part series on how to prepare for software requirement sessions to be most effective with your users' time (and yours!).

Can You Get All of Your Requirements In One Session?

There is general agreement in the software industry that talking to end users to gather requirements is critical to the success of the project. However, a common issue is that users are particularly busy. For example, if an organization decides to add features to a call center application, talking to the call center representatives is critical, but it’s also costly to pull them away from taking calls. In addition, requirements analysts are extremely busy and may have to limit how much time they spend with any one user.

A common issue in gathering requirements is leaving a stakeholder meeting where you missed major requirements because the “next question” to ask did not occur to you at the time. It is unreasonable to think that this will never happen. The reality of software requirements efforts is that they are iterative. In addition, there is quite a bit of critical analysis that must take place, and that analysis cannot always happen immediately in a meeting environment. Whatever the reason, there is certainly a need to get the most out of time spent with the users. So how do you best prepare for meetings with your end users?

Software Requirements Sessions Tip 1: Organize Your Time

Requirements analysts should realize that the software requirements life cycle can be time intensive - including time to analyze, edit, review, and update. The key is to maximize the value from everyone’s time.

Make sure that requirements sessions are well planned, inviting the minimal group of people necessary to get value out of the meeting. The burden of extra time spent should be on the requirements analyst, not the users who are being taken away from their primary jobs. Prepare an agenda and appropriate artifacts prior to the sessions in order to keep the meeting focused on making valuable progress.

In dealing with any super-users who are unable to commit much time, it is important to zero in on specifically what information they must provide. Then allow these users to suggest alternative users to meet with to provide additional information, ensuring them you will allow them to review what the alternative users provided.

Come back soon for part 2!

How do you prepare for a requirements session? I'd love to hear your answer in the comments.

Thomas the Tank Engine on Software Requirements

At my house, we recently entered the phase of fascination with Thomas the Tank Engine. If you're not familiar with Thomas and his many, many, many friends on the Island of Sodor, then you must not know anyone between the ages of 2 and 10, because they're a hit with that crowd. In fact, my son has decided that he'd rather "watch Thomas videos?" (said in his cute little "please" voice the first time) ... "watch Thomas videos" (said a bit more directly the next time) ... "WATCH THOMAS VIDEOS!!!" (you get the picture) than do just about anything else. So, I now am learning a lot about Thomas and his friends.

One of the most important things on the Island of Sodor is to be "really useful." The engines spend a lot of time worrying about whether or not they're being useful and trying to find new ways to be more useful. The highest praise a tank engine can receive is for Sir Topham Hatt (who runs the place) to tell the engine how useful he or she has been.

Being Helpful Isn't Enough

I've spent more time than I'd like to admit wondering why being useful is the most important thing on Sodor. Why not being helpful? Or being friendly? Or sharing? Or eating your vegetables? Or any of the other lessons that kids need reinforced? Is rail baron Hatt on to something?

When I put the question in terms of requirements work, it makes much more sense to me (which probably says something about the odd way I think). When working on a requirements project, it's great to be helpful and friendly and share (eating your veggies is a good idea, too, but of less importance in this case). However, all of those qualities may not actually help you do the job a requirements engineer is supposed to do.

Provide Useful Software Requirements Work

If I'm helpful in supporting existing processes which enable the project to fail, that's no good. If I'm friendly but let the stakeholders change requirements willy-nilly, that's no good either. And if I share the requirements information with the development team but they can't understand it, then what good have I done?

What's more important is that I do things which are useful to the project. I suggest (dare I say "implement"?) process changes which will help the project succeed. I force the business to make hard decisions about scope. I work with the dev team to make sure that the requirements are understood. And in doing so, I am "really useful indeed," as Sir Topham Hatt would say.

And then I eat my lima beans.

Bridging The Gap: Best Practices In Translation For Business Analysts

Requirements analysts often play the role of translator. They listen to, understand, and document the needs of system users in the users’ natural language and they present the users’ needs to system designers and developers in a more formalized ‘language’ made up of models and other artifacts. It is critically important to project success for the analyst to communicate effectively with both audiences.

Most analysts do this without really thinking much about it or examining the process and the best analysts do it quite well. But translation is actually a complex undertaking and it’s worth spending some time on it to understand what is really going on and exploring for ways to improve the process and the results.

Know The Requirements Process

The simple description of the translation process involves just two steps: Decoding the source content and re-encoding the meaning of the content in the target language. A more in-depth look at these two steps reveals some significant complexity. Translating from one ‘natural’ or spoken language to another requires that the translator understand the syntax, grammar, and nuances of both the source and target language. This is a much more involved process than simply taking one word at a time from the source and finding the equivalent word in the target.

For requirements analysts the task has a further challenge in that the target must be precise and rigorous while the source will usually contain vague and indistinct literary constructs that are normal in the everyday use of a spoken or written natural language.

Know The Language Of Your Target Audience

I could not find any research on translation specific to the work of requirements analysts, but there is a fair amount of evidence that deep knowledge of the target language is more important for a translator’s success than expert level fluency in the source language. The research suggests that while perhaps coding experience is not necessary, it is important for RAs to have extensive knowledge of the models used in requirements specification and this knowledge should be from the perspective of the consumers of the specification, designers, developers, testers, etc.

Research and best practices from the translation business also suggest that the draft translation should be reviewed by a second translator with deep knowledge of the source language.

Many software requirements analysts do have a background in software design and development but many come from other disciplines as well.

The ideal situation may be for the requirements specification to be first drafted by an analyst with deep knowledge and background in software design and development and then reviewed by an analyst with deep knowledge and background in the business. Not every project team will have access to the ideal mix of analysts but if your project does it may be worth a try.