The meaning of analysis and the importance of models

The basic definition of analysis is to break things down into smaller pieces to aid in understanding. In an organizational setting, it is useful to have a shared understanding of what processes the organization performs.

The best practice approach to communicating processes is with models. For the activities themselves we use process maps, aka process models. For the data collected before and during the execution of the those processes, we use data models. These are needed for any sort of functional specification. Every requirements effort should be centered on these two crucial techniques. No practitioner can be successful unless they leverage some sort of process and data models to consolidate and present functional requirements to all stakeholders. This most basic truth about functional requirements is that represent what processes are in scope and what data is associated with those processes.

The stakeholders need to be sure that their functional requirements are understood. Models do that. Paragraphs or lists of sentences that start with "the system shall" are dull, not concise, ambiguous and poorly accepted.

If the stakeholders insist on text based requirements, use models to create unambiguous, non-repetitive assertions. Most CASE tools can create these statements. For example, SADT/IDEF0 models can be written in the form: The Activity [Activity Name] transforms the input(s) [Inputs List] into the output(s) [Output List] according to [Controls List] using [Mechanisms List] as resources. Similar language may be adpated for DFDs, UML Activity Diagrams or other approaches. For Data modeling, the tried and true "Each [Entity Type Name 1] is [Relationship Name] [one and only one | one or more] [Entity Type Name 2](s). But for most of us, the models will contain 80% of the message of what is functionally required.

Welcome to AnalysisBasics

I have contemplated doing this blog for a while now. I am motivated by all the misinformation, fads and just plain bad ideas about how to business analysis. I believe I am qualified by over 20 years of professional experience in this discipline and others closely aligned. I also hold a Master's degree in Information Systems and have taught analysis a two accredited programs as an adjunct instructor.

Here is my working definition of what I mean by analysis: the function within an organization dedicated to understanding and communicating what/how things are done. This function is known by many names including:

• Business Analysis
• Systems Analysis
• Business Systems Analysis
• Requirements Analysis
• Enterprise Analysis
• Enterprise Engineering

and many others. My preference is for Organizational Systems Analysis, because the words "business" and "enterprise" denotes for-profit organizations. In my view and experience, not-for-profits like charities and government agencies can benefit from good analysis basics as well, no matter what they are called.

I hope others find this blog informative and enlightening. I welcome all constructive feedback, including critical opinions, as long as it not simply ad hominem attack or blatant written abuse.

Thanks for reading,
Todd