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?