Business Analyst Blog

I have been reading about software testing again, just surveying the market to see what new techniques and approaches have been invented. I have found that the basics are still in well-respected planning, preparation, objectivity, etc. What is amazing to me is what I don't see. Everyone has suggestions about how to improve your testing—implement a testing process or methodology, utilize IEEE standards, work towards CMMI compliance, etc. No one mentions that improving requirements will improve testing!

Testing software is an extremely time consuming and expensive activity. As software continues to get more complex the difficultly with testing increases exponentially. Why does it take so long? I would argue that one of the main reasons is that poor (or missing) requirements slow down the process as much as any other issue. If you don't have good requirements, how do you write a test plan? If you don't have detailed requirements, how do you write a detailed test case with a step by step procedure? If you don't have excellent requirements, how do you evaluate the software's ability to address the business problem. Instead of focusing so much time trying to improve our testing methods - let's spend more time writing excellent requirements - which are "testable" or "verifyable" and make our tester's lives easier!

For years I have been promoting a philosophy to IT solution teams centering on the need for clear, concise requirements.  Without excellent requirements the customer will never be completely satisfied.  I know, "never" is a strong word, but it is what I believe to be true. 

Teams that have an excellent Business Analyst and dedicate appropriate time to eliciting, documenting, and analyzing the requirements for a project are at a huge advantage in achieving customer satisfaction.  Teams can have the best Project Manager, the best development team or solution team, and the best Quality Assurance Analyst. But, if they do not have an excellent BA eliciting and managing the requirements for the project they will not be successful. 

Let's say you are working with a home developer to build your next home.  This developer has a proven record to get homes built on time and within budget, and the level of quality is not matched.  This developer never has punch lists when owners move in and very low maintenance issues.  When the project begins the only information given to the developer is that you need a 3 bedroom, 2 bath home with a 3 car garage.  In the end, the developer builds you a 3 bedroom, 2 bath home with a 3 car garage, on time, within budget, and no punch list items.  The problem is that you really need a ranch and they built a 2-story home, you need an attached garage, they built a detached garage.  You get my point. 

Clear, concise, detailed requirements are critical to the success of projects.  Does your team produce excellent requirements?  Does your team have excellent BAs?

A critical step in the analysis phase of a project is a formal review of the requirements package.  This will not cover how to conduct a formal review in detail, but the importance of a formal requirements review vs. a more typical, non-formal review which is common among project teams. 

Often project teams do conduct a requirements review, but there is no formal structure behind the review.  The review tends to consist of the following:

1. The package is distributed to the project team for review.
2. A 1-2 hour meeting is scheduled to discuss questions and feedback from the team.  Hopefully the package is reviewed prior to the meeting.
3. The Business Analyst (BA) makes necessary updates then re-distributes to the team.

On the surface this sounds good enough.  The team had time to review the document, have questions answered, and provide feedback to the BA on additional requirements that need to be gathered.

But, there is a major flaw in this type of meeting.  The meeting focuses on questions from the team members.  There may not be many questions from the team because everyone believes they understand the requirements.  Does the entire team have the same understanding of each requirement?  For instance, let’s say there is a requirement for a meal order system to validate that the patron selects three balanced meals (breakfast, lunch, and dinner).  The BA understands this to be that the meals meet dietary guidelines for a balanced diet.  The developer understands this as all of the meals need to weigh the same.  Everyone understands the requirement, but they have different interpretations.  This may not have been caught until later in the project when the cost to fix the problem increases.

A formal review must be conducted in the following manner:

1. Schedule time of participants
2. Deliver review materials
3. Review of materials by participants prior to the session
4. Conduct review session
5. Record review notes
6. Update material
7. Conduct second review session if necessary

In a formal review there are two major advantages over a non-formal review:

1. Each requirement is discussed to ensure consistent interpretation of each requirement by the team. The balanced meal requirement would have been clarified.
2. Notes are recorded in a consistent manner to help teams reduce the reoccurrence of defects in the requirements package.  This will improve the quality of the requirements package over time.

A formal review will take longer than a non-formal review, but we all know it is cheaper to discover and resolve issues earlier in a project than later.  Take some extra time to make sure all parties are truly in agreement with the requirements before the solution is being designed and implemented.  Over time, the quality of the requirements package should improve reducing the time to conduct the requirements review.

Please share your comments on successful and unsuccessful requirement reviews.

I have been using Yourdon's context level data flow diagram for about 15 years. I still find it one of the best tools for scoping project boundaries and getting everyone on the team to see the project in the same way. The only complaint that I have received about this diagram from my business stakeholders is that they want to know which business processes are going to be included in the project. Understanding the diagram gives you this information, but people who don't use the diagram frequently may feel it is missing a piece.

Because of this communication problem, we list the high-level business processes that are inside the project, right on the diagram. This gives the business stakeholders an explicit scope that they can review and approve. These high-level processes (usuallly about 5) give Business Analysts the starting point for detailed requirements gathering in the same way that the dataflow arrows and external agents do.

Once you understand a particular tool or technique, you can begin to modify it to better suit your audience. Our ultimate goal is clear communication, whatever technique we use. 

One of the unique aspects of the B2T Training Business Analyst curriculum is our focus on data requirements. Many of our customers initially tell us that their BAs don't do data requirements. I think they are identifying and documenting data requirements without really knowing it. I don't think that a BA can truly understand a business process without also understanding the information or data used to accomplish the process.

Many BAs document data as part of the business process or part of the Use Case. Our recommendation is that you document data in a separate part of the requirements package because it is often used in multiple places. Even if a project is small, I contend that there is always at least one data element that is used and the BA must communicate the requirements about that data element to their solution team. Where is the data element currently stored, what does it look like, who gets to change it, is it required?

Talking with SMEs about data and communicating these requirements to IT is a critical task of the Business Analyst. A requirements package that only includes process requirements is really just a half complete requirements package!

If you want to read more about data requirements download the issue of our magazine, the bridge, that focuses on this topic from our BA Resources Page.  

I was talking with a Project Manager recently. She said that she thinks most Business Analysts get anxious when a project, or idea for a project, is not well defined. In her organization, the initial phases of a project involve looking for business opportunities, thinking about strategy, considering if the idea is aligned with the organization's goals. I started thinking about her observations. Is she right? Are we as Business Analysts uncomfortable with an undefined "idea" about a potential project?

As always with business analysis my answer is: It depends! I do think that some BAs may be uncomfortable with the "fuzzy" nature of the task. We do like to get things done and we like to have a detailed understanding of the business needs. Having said this, I also think that some BAs are brilliant at looking at business opportunities/problems from a high level and "thinking outside the box" about options. One of the characteristics of an excellent Business Analyst is the ability to see the big picture and to see details. Even during detailed requirements gathering and analysis we should periodically step back to see the work from a broader perspective.

The reality is that all Business Analysts are not the same. I believe that our profession is going to specialize, just as many of the IT roles are specializing. Some of us will be more big-picture thinkers and some of us will be more detail-oriented. The good news is that there are lots of opportunities for us to bring value to our organizations!

I recently read an article written by one of my favorite gurus, Neal Whitten, entitled Do You Really Get Your Job? Neil is very big on accountability. He writes an article that reminds us to examine our jobs and roles and to think about whether we are performing in the best way possible or are we just doing enough to get by.

Whitten questions the role of a Business Analyst "who believes that her job is to give the client what they want, instead of what they need." I believe his comment is worth some self-examination. I might debate his definition of "want," but I think I understand too well what he is suggesting. For example, someone tells us they need a new screen and we tell the developers to get working on that. Are we really performing any business analysis or are we merely order-takers? What if your client's problem was more complex and the new screen isn't going to fix it? What if the screen desired was inconsistent with the rest of the application or what if the information to be entered on the screen would not be useful if it were collected? Why do they need the screen? What is the business problem to be solved? Hmm.

This reminds me when I was at a very nice restaurant and I thought I knew what I wanted to order. The wait person asked me several questions about what I really liked and suggested something totally different. I took his suggestion and was very pleased with the result. I was more pleased with what I received than what I thought I wanted due to the extra effort that this person took to understand "my true requirements." So if you are a Business Analyst who "gets" your job, take pride in your curiosity to investigate, analyze, and discover what is truly required. More often than not the Business Analyst really helps the customer understand more fully what they really need. We all know that time is money, but rework is even more money. I know we are all under time pressures to do things faster, but a great Business Analyst needs a strong backbone to say wait a minute lets figure out what you need first - maybe it is this new screen but maybe it is something else. Too often in these hurry-up projects the customer finds out too late that they paid for the wrong solution. They are not very happy with you then, are they? Next time your customer gives you a dictum, look them square in the face and ask a few probing questions-you'll feel better!

Does anyone have any bad experiences by giving a customer exactly what they said they wanted?  Please share your thoughts.

Whitten, Neal, "Do You Really "Get" Your Job? PMP Network, 2-2006.

Jason P commented to my May 8th entry that a model is not a requirement. I disagree. One of the changes that I would like to see in our industry is a broader use of the word requirement. A requirement can be represented as a sentence, or a symbol on a diagram, or both. For example: Jason says that requirements are derived from models. If I build a data model using an entity relationship diagram, I would not translate those "needs" (requirements) into a textual description (unless the business stakeholders demanded it). The fact that the business needs are represented in a diagram rather than a sentence does not make them any less needed.

I think that it is limiting for us to only use the requirement when we are talking about an English sentence that starts with the words "The system shall . . . ". I would like every artifact that we document to communicate a business stakeholers needs/requests/wishes to be considered a requirement.

I just reviewed an article on www.stickynotes.com

It Is Still The Requirements
Getting Software Requirements Right by James Ward

This is a very interesting article on the challenges facing a Business Analyst in gathering/eliciting requirements. Mr. Ward accurately describes the dichotomy "between those analysts who believe the customer is responsible for requirements definition and those who believe the customer is not capable of providing this information, at least to the level of detail and precision that is required …"

Mr. Ward suggests that an analyst must take the time to understand the business before true solution requirements will be identified. I agree. As much as we want to hurry up and get a new project done, the best solution is identified by individuals who clearly understand the business problem and the business environment. Software is not always the best or only solution. An excellent Business Analyst must understand what the business is trying to accomplish and the constraints around that work.

I don't like to hear analysts or developers say "The customer doesn't know what he wants!" Of course he doesn't know what he wants, he knows what he is trying to accomplish and needs the creative, knowledgeable minds of the Business Analyst and developer to help create/design a solution. At the beginning of a project, noone on the project knows what the solution will look like. The work of the Business Analyst and the technical team is to help understand the needs and constraints and design a solution that will answer the problem. If the customer knew what he wanted, we wouldn't need Business Analysts and we would not have so many problems with User-IT relations. The activity of understanding a business problem/opportunity and developing a solution to accomadate it is a very complex, difficult, creative process. It requires very well educated, logical, creative people who are open to new ideas and willing to work collaboratively with others to come up with the best solution. 

I just read an interesting article about the importance of using a "rule-driven business process management tool." It was written by Pegasystems who sells one! The article is called Six Myths of Rules and Business Process Management. See link below.

I think this supports several of our teachings:

1. Putting business rules in each process template reminds Business Analysts to gather both together.
2. Including business rules in our course Detailing Process and Business Rule Requirements supports the relationship.
3. Showing how rules are also related to data supports the need for multi-modeling and the importance of data.

To read the article visit Pegasystems.com. This link requires a registration and login to download the article.