Webinar: Requirements-driven testing

There's a webinar offered by Compuware called, Requirements-driven testing—The journey from business needs to test and user acceptance. The event will occur on February 6, 2007 @2:00 pm EST (11:00 am PST.) Here's a brief description of the event.

IDC’s research indicates that 70-80 percent of IT project failures result directly from poor requirements gathering, management and analysis. With a requirements-driven testing approach, you can improve the quality of your requirements, involve QA earlier in the life cycle and maximize the ability of your projects to deliver on all of their objectives.

Decisions and consequences

Early last year I wrote a post called, Thoughts on decision-making, where I outlined some decision-making techniques and myths. One item I would like to add to that topic is to understand the consequences and ramifications of the decisions you make.
Let's step back and examine this from a business context. Suppose we are working on a project and one of the requirements is simply, "to be able to process transactions from external sources." The design team proposes two solutions:

• Processing batch files
• Processing individual transactions (real-time)
  

Based on cost estimates, the batch file solution seems more appealing. One should consider whether, in the foreseeable future, real-time processing is desirable and whether the benefits of that approach will outweigh the increase in costs. It may turn out that the batch file design still wins out but the ramifications of the decision are fully understood and can be communicated.

You may think the consequences of a decision will be minor and short-lived, but they may become temporary like income taxes.

Tips for end-user acceptance

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

1. Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
2. Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
   
3. Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
   
4. Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
   
5. Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
   
6. Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
   
7. Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.
   

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Why we do things - ROI

Long ago, one of my professor's told me, "The purpose of education is to increase pleasure enjoyment." I've yet to fully grasp exactly what he meant (he was a professor of philosophy and often spoke in riddle), but I think it was something along the lines of, "Knowledge allows us to improve our station in life." It may take the form of allowing us to obtain better jobs, improve our ability to appreciate things or allow us to take better advantage of the opportunities presented to us.

Let's examine a familiar concept - investing. Whether it is because we want to be able to make a large purchase (a house or car), enjoy a comfortable retirement, or live out some of our dreams, most of us are putting money aside. This money is invested based on our individual risk / reward preferences. If you lie awake at night worrying about your investments, you may be outside of your risk / reward sweet spot.
Individuals who want to be safe, invest in financial instruments such as money market mutual funds, treasury bills or other assets where the risk of losing the investment is small (note that small risk generally implies small potential return.) Individuals with a higher risk tolerance purchase financial assets with higher potential returns.

The prudent investor analyzes their assets periodically to ensure a suitable return on investment (ROI) is being realized. There is a good guide on ROI available on SearchCIO.com explaining basic ROI concepts from a business perspective.

I want to introduce another concept - opportunity cost. Opportunity cost is defined as:

The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.

In business, all else being equal, you fund projects that have better rates of return for your company. Businesses use capital from their shareholders and money they've borrowed to fund their projects. Furthermore, a company is expected to invest in projects with ROI that exceeds their opportunity costs (e.g., projects that make them grow!) From the perspective of an individual investor you probably wouldn't be willing to purchase shares in a company that wasn't trying to increase its future earnings. Would you?

Thus, in business the ultimate goal is to increase profitability. A business does this by undertaking projects that are expected to yield a return above their opportunity cost. These projects have specific goals and objectives that support the business' strategy. This is why it is important to tie requirements back to business goals and objectives. As well as business goals and objectives back to strategy.In business and in our personal life, we do things to improve, to grow, and as my old philosophy professor would say, "...To increase pleasure enjoyment."

Tips for Business Intelligence

There was a short set of slides posted on BaselineMag.com outlining 6 Tips for Business Intelligence Success. Make sure you check it out. The tips are:

1. Understand your enterprise
2. Involve key users
3. Make sure components of a BI system work together
4. Be mindful that different employee groups will want different interfaces
5. Consider making applications broadly available
6. Create a competency center

Some of these tips are applicable to normal business analyst engagements as well.

How "bad" requirements can stifle innovation

A great way to curb innovation and creativity is to impose improper limitations.

Limits by themselves are not bad. Clearly a project needs to operate within a set budget, resource allotment and delivery schedule. These types of constraints can actually spur creativity and novel solutions.

But let's think about business requirements and how improper requirements can hinder the process of innovation. More specifically let's examine how requirements that are not design independent can unfairly constrain a solution to a business opportunity (or problem.)
Many times during my requirements gathering and elicitation engagements I have heard subject matter experts and clients tell me their requirements based on existing applications and functions. They assumed that the products delivering the new capabilities they desired would actually be enhancements to the existing applications. In truth, the eventual solution may be based on an existing one (particularly with software products), but this is not always the case.

Suppose our company designs cars. The newest set of requirements for the upcoming model year state the driver has the ability to:

1. Determine where he / she is (e.g., location) at all times.
   
2. Receive driving directions to a user specified address.
3. Interact with the system through the car's dashboard.
   

By themselves, these requirements seem fairly benign. Suppose our project advanced to the stage where we are developing a solution to meet these needs. Our team decides that a global positioning system (GPS) is required. Based on the third requirement, it is decided that an on-board system similar to Onstar is appropriate. Implementing this solution requires our company to purchase units of the GPS product and integrate it into our assembly (line) process.

Nothing appears terribly wrong with the proposed solution, but what if the car model in question is marketed to first time car buyers and students (people who want to be sporty but on a budget.) Large scale changes to an assembly line are costly. Acquiring GPS units and integrating them into a car's electronics are expensive. The cost of the new model will increase as a result.

Because of the third requirement we have ignored other solutions that may have been more optimal. Perhaps we could have offered portable GPS systems (e.g., Tomtom's) to people who purchased our vehicles. Our needs would be met in a more cost-effective manner.
The third requirement constrained our innovation and creativity to the point where a more optimal solution was missed. This is how a requirement that is not design independent can stifle innovation and creativity.

Understanding the goal

When gathering requirements, one of the most important things to understand is the answer to the question, "Why?"

The answer to this simple question will provide clarity and guidance to your requirements gathering efforts. This is because you will be able to evaluate whether the requirements you are gathering will solve your problem (or capitalize on the opportunity.) Thus, a business analyst should always seek to understand the underlying business objective.

Suppose a client receives five sets of different reports. The client is concerned because it takes him a long time to get the necessary reporting. His request is for his five reports to run faster so he can perform his analytics. The business analyst (doesn't probe any deeper and) works with the IT developers to optimize the SQL used in the reports, create database views to reduce the number of multiple-table queries and revamps the reports so they are more efficient. Finally, the business analyst presents five optimized reports. The client promptly looks at each report, takes two pieces of information from each and then creates a dashboard sales report for one of his customers.

If the business analyst knew that the goal was to prepare a dashboard sales report, could a more optimal outcome have been achieved?

Here are a few comments about what happened:

1. The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
2. Ultimately, a useful result was obtained however, it may not have been the most optimal one. The business analyst also ran the risk of not achieving the goal at all because the business analyst did not probe deeply enough to uncover the underlying objective.

If the business analyst had used active-listening techniques and probed the client, both of these issues could have been avoided.

Setting expectations

In the business world, a key part of communicating is expectation setting. Whether you are delivering a presentation or a set of requirements, not establishing expectations with your audience can lead to a few unfortunate outcomes.

1. Your material is perceived to be unsuitable. It may be too detailed or contain too few details.
2. People may require you to perform additional work to produce something more acceptable to them. You'll get comments like, "I won't sign-off on this unless I see... such-and-such in there."
3. Your work is not perceived to be relevant. You'll be asked to go back and start over.

In marketing, there is a saying that, "If you do not position your product, someone will do it for you." Likewise, when communicating, "If you do not set expectations, they will be set for you." Think of what happens when you watch a presentation (or attend a meeting) with 10 other people. How many of them say things like,

• I didn't get anything from that.
• That wasn't what I expected.
• There were no details, I need details.

If you hear these sorts of statements, it indicates that people did not have a clear idea about what to expect and why there were there. In other words, the individuals responsible for delivering and setting up the presentation (or meeting) did not clearly articulate their intentions.

In one of my previous posts, I wrote about expectation setting as it related to the development of requirements. What resources you'll need access to, what tools you will be using, how you will be providing status updates and the facilities to provide feedback (and ultimately sign-off.) The last part of this is to explain and outline what will be in the actual deliverable.

Before I start writing about expectations for deliverables, recall that there are many different phases to a project's life cycle and for each one, different levels of information and different audiences are present. For each, a different expectation needs to be established.

Spotlight: business analyst

Allan Hoffman recently posted an article on Monster.com, Career spotlight: Business Analyst.

He lists the main factors for requiring more business analysts as:

1. The increase in outsourcing patterns.
2. A continuous drive for improved efficiency.
   

Mr. Hoffman points out that the most important thing a business analyst can bring to a project is translation; or a furthering of understanding about what is required.

Kathleen Barret, president of the International Institute of Business Analysis (IIBA), says business analysts' ability to translate -- an ability that's difficult to offshore -- is crucial to succeeding in the role. "[Business analysts] need to be there with the business," she says. "It's very difficult to do a good job virtually."

This echoes my thoughts from an early post, The why of business analysis. The central role of the business analyst is to foster understanding throughout the business and IT groups to provide the best basis for success.

Step back for a second, think about how easy it is to misunderstand and miscommunicate. Think about the costs and consequences associated to some of these misunderstandings when they happen on your projects.

Unfortunately, they aren't as humorous as the following video.

Stop 'gathering' IT requirements

There's a post on Techrepublic titled, Project Managers: Stop "gathering" IT requirements.' It's an interesting read.

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The author, Paul Glen's, point is that, "project managers should negotiate requirements among the stakeholders." My comments on the article are as follows:

• In order to negotiate well, a project manager really has to understand the nature of the project and client ask. If the project manager doesn't understand the ask (e.g., isn't familiar with the business), a strong supporting cast is needed to keep everything real. Are you more confident when you know your project manager has lead projects similar to the one you are on or is very familiar with the industry?
  
• Requirement 'gathering' means collecting requirements, however, a business analyst is paid to understand them, derive meaning from them and then communicate the underlying business objectives. To me, this is the core competency of the role. The article does not really talk about this. You do not need a business analyst to order take.
  
• The following comment from the article seems a bit over the top, "We should think of a set of requirements as being like a multilateral treaty among a group of nations." I understand the need to have clear understanding and expectations, but this sounds like something people do when they don't trust each other.
  

I think, if anything, this accentuates the need to have a strong capable business analyst.

Slides available: The project and the business analyst

I've been running around giving a lot of presentations recently. I'm going to start making some parts of them available for interested people. Please feel free to provide any feedback you may have on either the content or my slide design. I don't mind if you distribute them, but I ask that you credit appropriately. Thanks!

The first set of slides I'm making available were used on my post, The project and the business analyst. You can find them on esnips.com using this link.

INDEX for business analysis

Starting out:

• First things first; learn the skill: Understand how to structure and write requirements before you start using requirements management tools.
• Asking questions and getting answers: Learn how to ask questions to get answers to the important issues.
• Why you need good requirements: Some quick facts on project success and requirements. Presentation available.

Requirements:

• What are requirements?: A quick definition.
• Correctness: There are some things you just can not do.
• Completeness: Make sure that all of the, "what," questions are answered.
• Clarity: Requirements should be succinctly stated; using as few words as possible. Otherwise, ambiguity may occur. Excessive rambling, jargon & wishful thinking confuse readers -- avoid it. So it's still not clear?! Here's a short presentation deck recapping all of these items (the presentation is simply called Clarity.)
• Consistency: I hate it when people say, "Turn right. Your other right!"
• Testability: Prove to your client that the solution meets their needs. When a statement contains multiple requirements it's testability can be compromised.
• Traceability: What requirement led us to do this? How much work do we have left?
• Modularity: Update in one place and only in one place. Makes change management a lot less painful.
• Feasibility: Do you really think with enough time and money you can solve any problem?
• Design Independence: It starts with what and why. How comes later.
• Requirements vs. requirements management: Gathering requirements and managing them.
• Assessing requirement quality: How do you know if you have decent requirements?

The why of business analysis:

• The business analyst & the business systems analyst: What's the difference?
• The why of business analysis: What purpose and role do business analysts serve?

Running a business analysis engagement:

• Prepare thyself - make sure it's not you: Make sure you're mentally and psychologically ready and able to work. Eliminate any preconceived judgments and notions.
• Know the situation: Before you start an engagement take some time to grasp the nature of the project, it's urgency and the resources you'll need.
• Choose your tools: Decide what approach you will use. Will you prototype, interview, brainstorm or observe behavior?
• Set expectations: Ensure your role on the project is clearly defined and that you understand the roles of others as well.
• Time estimation: Estimate how long it will take you to complete your tasks. As you run through more projects your estimation skills will increase.
• It's the little things... Words that should make your ears perk up: Little words that your clients say that create headaches for you unless you clear them up now!
• New! How are your business analysts doing? Understand how to assess them.
• New! Understanding the goal: Knowing the objectives of your requirements gathering sessions helps you determine whether the requirements you are getting will actual help to solve the problem.
  

Project Bits & Bites

• How do you know you're done?: Use requirements management practices and traceability to see how much work you've done and how much you have left to do.
• Well-done or done well?: Use cost-benefit to determining where to invest your energy.
• System development life cycles & requirements: A very high-level overview of different system development life cycles and how this impacts requirements gathering.
• The project and the business analyst: Understand your role in a project and the activities you'll perform to support the initiative. Slides available!
• The sweet smell of success: Measuring success on a project ultimately boils down to meeting or exceeding targets established earlier in the project.
• Choose a methodology that suits your project: No one methodology will fit all projects.
• Testing & Validation: What are the different types of testing that occur as a project moves forth? Slides available!
• New! Requirements in an agile world: Understand that impact a different project methodology will have on requirements.
• New! Setting expectations: It's important that people know what you are delivering and why.
• New! How a "bad" requirement can stifle innovation: A lack of design independence in requirements can lead to a sub-optimal solution.
  

Asking questions and getting answers

In the old days ya could just wack a guy and be done with it. Now everyone's feelings are involved.

That quote is from the movie Knockaround Guys. Not a great movie (it's quite bad actually) but an interesting quote from John Malkovich's character. When you look from the perspective of a business analyst, one of the most important things a business analyst can know is the answer to the question, "Why?"

• Why is this important?
• Why do you want this?
• Why? Why? Why? Why? Why?

Some individuals take offense to this sort of questioning. They misinterpret the question to be a challenge to their statements rather than the educational exercise it really is. Understanding "why" will basically allow you to determine whether you are going in the right direction. How does this requirement align with what the project is trying to accomplish?

To avoid receiving a chilly response to your "why" questions, you can do two things:

• Prep your client as to the purpose of the "why" questions. Explain that understanding the rationale will allow you grasp the essence of their desires.
• Word your questions to be non-threatening (e.g., cater for people's feelings.). As suggested in this post from Tyner Blain, use "what" and "how" questions to answer the "why" questions.

Ultimately, you are trying to foster a strong working relationship with your client. Understanding how to question them and get the answers you need in an open environment is paramount.

Well-done or done well?

I remember flipping through the channels on TV and finding an interview with George Lucas (yes, that George Lucas.) The interview occurred shortly after the release of the Special Edition version of the first Star Wars trilogy. The interviewer asked George Lucas how complete the original trilogy was now. Mr. Lucas' answer was that he felt the movies were about 85% complete. The obvious follow-up question then became, "Are you going to revisit them and complete them?" The response was:

"A movie is never finished, only abandoned."

I wondered if this quote had any bearing on requirements and projects in general. My experience is that when you ask end-users what they want, a lot of them have a tendency to ask for everything under the sun. Features and requirements that probably would never be used by the vast majority of end-users will surface. Feature creep and change requests galore!

As a business analyst or business systems analyst you have a few cards to play to counter this.

1. Sometimes it is too early in the requirements gathering stage to get that specific. If you do not understand the general concepts and objectives, then getting into the nitty-gritty will not help. If this is happening to you, just ask your client to help you understand the big picture while stating that you made note of where you parked their thoughts so they can continue later.
   
2. When you prioritize things using cost-benefit analysis and dependencies, many specific features will become less and less important. Remember, not everything that is asked for necessarily is provided (refer to How do you know you are done?)
   
3. At some point in time, the team will need something they can work with. Lock-down the requirements for the iteration. Any changes require either a formal change request or must wait until a later iteration.

Number 2 in the list, implies that not everything will be developed. I think people have a mind-set that everything they have asked for is important and should be provided. But, as you know, some things are more important than others while other items are not important at all.

I would rather spend my time getting the most beneficial and important features done correctly than waste time chasing after one-offs. After all, use of your time is an investment. Would you rather invest in more profitable activities or not?

Prepare thyself - make sure it's not you

Giddy up!

As a business analyst preparing to embark on a new engagement you have gotten yourself ready by:

• Reading existing documentation such as charters and business cases.
• Holding informal conversations with individuals knowledgeable of the project.
• Researching external sources of information for background knowledge.

You have also got your wealth of experience accumulated over your career as a business analyst and beyond. So now you are ready, right?

I think I'm going to lose it!

Over my career as a business analyst, I have seen other business analysts pulling out their hair in exasperation over the lack of progress they are getting or the issues they are having dealing with their clients. I had the exact same thoughts go through my mind many times as well. You think,

• "They don't get it!"
• "They won't listen to me!"
• "I know more about it than them!"
• "That's got to be one of the dumbest things I've ever heard!"

Prepare thyself - mentally

I suggest some mental preparation for an engagement is also needed. Before you start:

1. Remind yourself to stay open-minded and non-judgmental.
2. Be ready to hear and understand, using stoic patience; if needed. There is a difference between listening to someone and hearing them.
3. Treat this like a negotiation. Endeavor to maintain your composure at all times.
4. Be willing to accept that your initial ideas may not be correct. Let them go.
5. Read this poem, Rudyard Kipling's IF, and understand what's being said.

But what if you are already in the meeting and you are starting to lose it mentally?

1. Remember your objectives.
2. Remember you should always be building relationships.
3. Breathe as deeply as you need to (try not to be insulting and do not roll your eyes.)
4. Take a short break to recompose yourself. "Bio break anyone?"
5. Cultivate ideas. Review and debate them later.

Make sure, that you are mentally focused and ready for the task at hand. If it was easy, they would not need you.

The why of business analysis

What is the role of business analysis? One might say that the goal is to help provide better solutions to meet business problems or capitalize on opportunities. Someone else may say that the goal of business analysis is to allow an organization to improve and develop. I think that the answer is more basic than that. To me, the objective is simply to communicate ideas.


Eureka! The objective is to communicate
This sounds like a very easy thing to do but it really is not. First off, a business analyst must understand what business clients need. Gathering this information can be a very tedious process. Sometimes business clients are merely listing out symptoms of a problem but not the actual root cause. In other cases, clients just do not feel that they need to provide much information, "It's obvious to me, why isn't it obvious to you?"

Business clients speak in their native tongue; full of company jargon, industry jargon and obscure references. Even worse, sometimes a lack of objectivity is apparent and rose-colored glasses are used. However, through diligence and perseverance a body of requirements will take shape.

Now it is time to relay the business clients' needs to the IT groups. These groups have their own subtle nuances. IT groups also make use of their own set of terminology. Sometimes the same terminology and expressions that worked so wonderfully with the business clients leave IT groups completely dumbfounded. Have you ever seen the, "That's got to be the dumbest thing I've ever heard," facial expression? Or perhaps the, "In English please," expression?

Eureka! The job is to translate!
It is almost like a business analyst has to act as a translator; deciphering ancient Greek and translating it into modern English so it can be enjoyed by a specific audience. Perhaps that is the objective of business analysis; to translate (ensure the clear communication of ideas.)

In closing
Have you ever attended a meeting where two people saw the exact same thing, got into a heated argument about who has the correct interpretation, and you sat there stunned because they sounded like they were both arguing for the same thing?

A zebra is a white horse with black stripes. No, a zebra is a black horse with white stripes. At the end of the day, they both represent the same thing.

The two parties simply could not understand each other. They needed someone to bridge the gap. To translate and facilitate the communication of ideas.

They need a business analyst!

The business analyst & the business systems analyst

In the past, I have asserted that when gathering high-level business requirements, one must aspire to be design agnostic. This is because the consequences may be severe if an inappropriate solution influences a requirement set.

Eventually, there will come a time when a solution must be defined. As a project progresses through the design stage of a system development lifecycle, the methodology, tools, 3rd party applications and approach have already been agreed upon. At this time, requirement documentation becomes much more detailed.

The BA vs. the BSA
So what is the difference between a business analyst (BA) and a business systems analyst (BSA) anyway? I've worked at a few different companies and seen the two terms used synonymously. But from company to company, there is a vast disparity in meaning.

For me, the distinction lies with whether the analyst is more closely aligned with the business side of things or with the IT side. Business analysts interact with the business to understand what is needed. The BA then liases with the design team (or through a BSA) to transfer knowledge of the business' objectives and needs.

Contrast this with business systems analysts who create specifications (to fulfill the business requirements) and interact more closely with the development & design staff. A BSA will generally tend to have more technical expertise than a typical BA.

Determine the skill set needed
Because of the varying composition of project teams and skills, individuals in BA or BSA roles may be asked to perform many different types of duties (as well as aspects of a BA and BSA role.) Rather than debate whether someone is a BA or a BSA, focus on how he or she has been involved in past projects.

During the different stages of a system design lifecycle, what was the role that was played?

Does the role require someone to be involved at the inception stage of a project or is the majority of the role to provide IT teams with specifications?

Does the role require a significant amount of client interfacing or does the role require significant technical knowledge?

What gaps in the team is one trying to fill?

Spend time understanding what is needed rather than what to call the role.