What is Analysis?

Author: Geri Schneider Winters

As Business Analysts, our job goes far beyond being a note-taker, in other words listening to people talk, writing down what they say and calling it requirements. Notice that the term Business Analyst implies that we analyze. We need to analyze requirements and information and that is some of the skill we bring to the table. Andrew Midkiff and I were having lunch the other day and discussing what analysis means to us as working Business Analysts. And we came up with at least a couple of different things that a Business Analyst should do that are called analysis.

Andrew thinks of analysis as Requirements Analysis. So I asked him what he meant by that. A lot of people use that term, but what do they mean? He said Requirements Analysis is looking at the information that you are provided and analyzing it. It is a process where you probe and question to tease out the actual business needs that require a solution. You should be asking these kinds of questions:

  • Where is there a lack of information?
  • Where do you have not enough detail?
  • Do the requirements as they are given to you make sense, i.e. are these truly things that are required of the solution?
  • Does the information you were provided describe actual “requirements” in a business sense or something else, such as solution?
  • As you compare all the requirements and use cases you have collected to each other do they make sense as a whole? Is this a cohesive, accurate description of the project?
  • Has the stakeholder given you true requirements of the system, or rather a description of how things work today?

In this kind of analysis we really want to probe and question. I remember one company I worked for, an insurance company, there was a project to create a system to use to input applications for insurance. They were going to store information about the subscriber using a unique identifier, which was a good idea. So there was a requirement – “The system has to uniquely identify the subscriber”. But then they were going to store dependents of the subscriber by first name, because they assumed that would be unique. I probed and questioned, I asked them does this make sense. I gave some examples. Look at the example of George Foreman who named all of his children George Foreman. In a more common example, my sister was married and had a daughter she named Heather. She was divorced, and remarried a man who had a daughter named Heather. So now there were two Heathers in the same family. In both of these cases we have direct dependents of the subscriber who have the same name. This shows that the requirement to identify dependents by first name was a poor one. The requirement was rewritten as – “The dependents of a subscriber have to be uniquely identified within that policy.” As an Analyst it is my job to question that kind of thing, to really think about what I am being told. To question it and probe and make sure it really does make sense.

In a different perspective from Andrew’s, when I think of analysis I tend to think of information analysis. This is where I like to use something like a class diagram to show pieces of information and the relationships between the pieces of information. And I like to use a state diagram to show a particular piece of information and its states. What I am looking for is how the information changes over time and what causes those changes to happen. I’m not so interested in finding all the attributes of the class (or piece of information), but rather I want to know what about that information causes changes in my business process (or what in my business process causes changes in the information).

When I do that information analysis, I’m really looking at a perspective that cuts across the use cases. The use cases each describe individual processes. Then the information analysis goes across those processes to show how each of those processes contributes to some change in the information. This is also how I’m finding more business rules or triggers about what happens in the business over time as information progresses through the company.

 

Post a comment and let me know – when you think of analysis, what do you mean by it?

Are your thoughts more like mine, Andrew’s, or something different?

 

6 thoughts on “What is Analysis?

  1. Praveen Rao

    Hi Geri

    It’s a very informative article defining basics of the Business Analysis. Good one.. I am regular reader of your articles. I am a junior business analyst and all these articles helps me to gain more knowledge.

    Thanks.
    Praveen Rao

  2. Joris de Vrede

    Hello Geri,

    It’s interesting that you see Information Analysis as a part or just a different term for Business Analysis. I always thought of these as two separate functions. BA being a matter of business case creation and / or business process analysis. IA is more concerned with information objects and information flow. Well it was at least in my book.

    Regards,
    Joris de Vrede

  3. Michael Larsen

    Hello Geri,

    I agree with both explanations of analysis within this context. I come from a systems engineering (defence) background. I view a business as a systems so when I analyse a business (system) I review the information from several perspectives. People (designers, users, stakeholders, and clients who is paying for the system) Product (the actual physical system), Process (this is the soft system and hard system combined), Project ( Project Mangement, Developers, Architectue, Testing). I want to know the static information contained in the system, what are the inputs of information and interaction, the transformations of information and functions provided by the system (hard and soft) and the outputs and outcomes of the system. I use several tools that provide me information about the project, processes, product and people to accomplish an appropriate analysis of the information I have gathered

    Context Diagrams ( the world of the soft system and hard system) – product and people
    Stakeholder diagram (people, project) a good website is Ian Alexander’s http://easyweb.easynet.co.uk/iany/consultancy/papers.htm
    Activity Diagram (people, process, product) I like this tool to identify and categorize the activities as a whole plus activities associated with a specific actor
    Use Cases (people, process, product) I like use cases because of the serial progression of the workflow and is written compared to a diagram in an activity diagram.
    Data Dictionary (people, process, project, product) I find this to be one of the most important tools to identify ambiguous, incorrect, and missing information because creating a Data dictionary forces the writer to attempt to describe what the term means this definition can be used to test the usage of the term through out the provide information.
    Behavior Trees (process, product, project, people) I use this tool on almost any type of information provided because it shows an integrated view of all of the important information and can identify issues such as ambiguities, incorrect information, missing information, timing and alias terms. It incorporates component models, behavior models (use cases, activity diagrams) in a two view representation of the requirements. If you want more information go to http://www.behaviorengineering.org.
    There are many more tools/techniques I use but these are some of the main ones I use.

  4. Angel Fitchett

    Good Day Geri,

    I too appreciate your articles. I have 12+ yrs as a Business Analyst and now am Sr. BA and will perform the role of Project Manager when needed. Your articles help me keep abreast of anything new and to help be ensure that I have not forgotten some skills that may not be used in a particular work environment.

    Thank you for your expertise, time, and sharing.

  5. Andrew Midkiff

    Wow. I am somebody. 🙂

    Hey, Geri!

    I tend to break the Requirements Analysis down into two main areas: business needs analysis, and user needs analysis. I differentiate the two because sometimes they can be in conflict, and/or have different motivations. Underlying both of these is the Information Analysis you mention. You never have business needs without information needs.

    User needs can have an effect on your information requirements in many, and sometimes surprising, ways. Because user needs are more informed by human beings, they can sometimes take a surprising turn. In the example you mentioned, where a person can have more than one child of the same name, if I am the user of the system where I have to enter and keep track of these co-named siblings, I would want some very obvious way of keeping track of which one I’m talking about.

    For example, think of the customer service person talking to the subscriber, how do you keep track of which Heather you’re discussing? It is very important for lots of reasons to make sure you enter the right information for the right person. This becomes a user interface problem that may affect how you structure your information.

    So, in the end, it’s all tied together and interrelated. You cannot do business process analysis without understanding the information needs of that process, and you may also need to take into consideration the users as well. Hey, if it was easy, they wouldn’t need us. That’s why we’re paid the big bucks. Right? Right? Hello?

  6. admin

    Thanks for the additional insights Andrew!

    It is a big job, isn’t it. There is so much to consider and keep track of. But that is the fun of it for me!

    Geri

Comments are closed.