Skip to main content

How to Analyze Stakeholder Requirements

FEATUREAug6thCopyright 2013 Marcos Ferrer

When I was very young I asked my father what he did.  “I’m an analyst.”, he told me.  “What’s that?”, I asked right back.  “I spend my time thinking,” he answered.  “Thinking about what?”, I insisted.  He laughed and replied “All kinds of stuff – anything they want!”. 

I didn’t know what to ask after that.  Thinking about “anything” meant thinking about everything.  I was not yet old enough to know everything, and was overwhelmed at the thought (now I am too old to know everything – it was fun while it lasted). 

In recalling the incident I realized that I do know a lot more about analysis than I used to.  To explain analysis so others can take action in their jobs requires some very hard thinking.  Hard thinking is the BA’s favorite job*.  SO – let’s Analyze Analysis! 

Maybe dictionary.com already explained analysis for us?  Let’s see their definition:

a·nal·y·sis [uhnaluh-sis]

noun, plural a·nal·y·ses [uhnaluh-seez].

  1. the separating of any material or abstract entity into its constituent elements (opposed to synthesis).
  2. this process as a method of studying the nature of something or of determining its essential features and their relations: the grammatical analysis of a sentence.
  3. a presentation, usually in writing, of the results of this process: The paper published an analysis of the political situation.
  4. a philosophical method of exhibiting complex concepts or propositions as compounds or functions of more basic ones.
  5. Mathematics .
    1. an investigation based on the properties of numbers.
    2. the discussion of a problem by algebra, as opposed to geometry.
    3. the branch of mathematics consisting of calculus and its higher developments.
    4. a system of calculation, as combinatorial analysis or vector analysis.
    5. a method of proving a proposition by assuming the result and working backward to something that is known to be true. Compare synthesis.
  6. Chemistry .
  7. intentionally produced decomposition or separation of materials into their ingredients or elements, as to find their kind or quantity.
  8. the ascertainment of the kind or amount of one or more of the constituents of materials, whether obtained in separate form or not. Compare qualitative analysis, quantitative analysis.
  9. Psychoanalysis.
  10. Computers. systems analysis.

Other sources allow us to expand the above:

Wikipedia:

Analysis is the process of breaking a complex topic or substance into smaller parts to gain a better understanding of it.

Applicants (for topics related to analysis)

  • 1.1 Chemistry
  • 1.2 Business
  • 1.3 Computer science
  • 1.4 Economics
  • 1.5 Engineering
  • 1.6 Intelligence
  • 1.7 Linguistics
  • 1.8 Literature
  • 1.9 Mathematics
  • 1.10 Music
  • 1.11 Philosophy
  • 1.12 Psychotherapy
  • 1.13 Signal processing
  • 1.14 Statistics
  • 1.15 OTHER…(emphasis mine)

And, of course, many other authoritative sources, such as BA-elzebub’s Glossary which defines A, BA & MBA (Analysis, Business Analysis, & Monkey Business Analysis).

The question is not about WHAT can be analyzed. ANYTHING might be analyzed.  Priorities change, and focus must shift.  The first question is actually HOW?  How does one DO analysis, business analysis in particular?

BABOK gives a starting point.  It analyzes business analysis by breaking it into parts – in this case, the 6 Knowledge Areas and the 32 BA tasks.  Since our stakeholder has given a “requirement”, let’s look at the “Requirements Analysis” knowledge area.

The first task of “Requirements Analysis” is “Prioritize Requirements”.   It makes sense to work on “first things first”.  How do we prioritize?  This can be especially tricky when presented with stakeholder stated solution “requirements” instead of an explicit business case (see the Schmision, Part I).

Let’s say a stakeholder wants to implement some new reporting.  When asked what information needs to be reported the stakeholder responds “everything” (no, really, it can happen J).  Further elicitation may reveal a short list of ideas or items of interest.  Such an elicitation (forgive any over-simplification) might be stated, documented and confirmed to the stakeholder (not yet analyzed into a solution requirement) as follows:

Department Help Desk needs new reports to help reduce the costs of servicing “internal customers”.  These reports should show everything J, including but not limited to:

Costs of servicing internal customers
Department costs of internal customers served
Team costs of internal customers served
Types of internal service provided and costs
Who gets most internal service
Who gives most internal service
Where we can save resources
More…

Notice that it is not trivial to “prioritize” this requirement.  Prioritization requires more than one requirement.  Perhaps the “prioritization” work can be found by analyzing the list.  “Where we can save resources” seems like a high priority, but what report can tell us this?

This situation is typical of stakeholder requirements of all sizes and complexities. These are often handed out with minimal analysis (“We said what we want”) and with no rational hints about priority (“Do this ASAP”, or “Do all of it, don’t be late”). 

How can we use analysis to add value here?  With one overarching requirement, we work on the one we have.  The Prioritize Requirements task is easy for the moment.  To add value, we start with the stakeholder’s list, slightly modified to simplify and abstract the ideas.  We apply the Specify & Model task, using an outline text model:

Attempt to Analyze Stakeholder Requirements [Stated, Confirmed] for the Everything J About Servicing Internal Customers Report Project – EASICRP:

  1. Internal Service Costs
    1. Total Costs
    2. Costs by Department
    3. Costs by Team
    4. Costs by Service Type
    5. Costs by Service Recipients
    6. Costs by Service Providers
    7. Costs by Chances to Save Resources
    8. More…

Still modeling, we use outline logic (“Some of these things, belong with the others, some of these things just aren’t the same.”) and get:

  1. Internal Service Costs
    1. Total Costs
      1. Costs by Department
        1. Costs by Team
          1. a.    Costs by Service Providers
      2. Costs by Service Type 
      3. Costs by Service Recipients
      4. Costs by Chances to Save Resources
      5. More Cost views …

Still modeling, we use outline “rule of thumb” – if you have one of something, you probably have another.  If you don’t, you may have a gap.  Figuring this out is adding value to the stakeholder’s analysis – “by being more complete, we may reduce requirements risk.  We get something like the following, using ??? for additions by the analyst, pending further analysis and/or validation by stakeholders:

 

  1. Internal Service Costs
    1. Total Costs of Internal Service by Organizational Structure
      1. Costs by Service Provider Department
        1. Costs by Service Provider Team
          1. Costs by Service Provider (???time/effort)
          2. ???Other incidental costs (overhead/supplies)
        2. ???
      1. ???Costs by Service Recipient Department
        1. ???Costs by Service Recipient Team
          1. ???Costs by Service Recipient (time/effort)
          2. ???Other incidental costs (overhead/supplies)
        2. ???
      1. Costs by Service Type
        1. ??? On boarding
        2. ??? Annual Training
        3. ??? IT Help Desk
        4. ??? HR Guidance
        5. ??? More… 
      1. Costs by Chances to Save Resources
        1. ???
        2. ???
      1. More ???Cost Views…
        1. ???
        2. ???
  2. ???Internal Service Benefits
    1. ???Etc.
    2. ???Left as an exercise for the reader, similar to above yet different.

Although we have expanded the original stakeholder requirement, it is still unclear what is or isn’t a priority.  The focus so far seems to be on WHO DID IT, an approach that has been deprecated by many great (and late) business leaders, including Robert Townsend of Avis (“Up the Organization” remains relevant to this day) and especially Edward Deming.

More trivially, I have unfilled “outline” spots – this often suggests that further analysis can help, but what analysis?  Drilling the “solution” in this case is not giving my inner BA the warm fuzzies.  Thank goodness it only took an hour.

When in doubt, learn more. Next month we illuminate our Stakeholder requirements with traceability to Business Requirements, and discover the source of BA’s increasing popularity.

Food for thought to my thoughtful readers:  One way to understand a thing is to understand what it is not.  The opposite of analysis is synthesis. Does this help you?  Seems to me that synthesis is as much the point as analysis in what we do.  Tell the IIBA, especially if you are a part of the Practice Survey!

* Hob, hob, hob, with thanks to Bob Borden and Jeff Ring of Illinois.

Don’t forget to leave your comments below.