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

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?

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.

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.

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

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