Everything We Need to Know We Learned on Sesame Street

“Some of these things, are just like the others, some of these things are not quite the same, can you guess which things…” Analysis is the “anti-methodology”, always seeking coherence, relationship and significance rather than exclusion.

Let’s use some BABOK categories to organize stakeholder “stated requirements”. In the process we will see how we can distinguish “requirements” from requirements when we model potential solutions.

Let’s say your stakeholders have stated things like:

1. We want to reduce data entry errors
2. We want to increase sales
3. We don’t want to change the work or conditions
4. We want easy to use
5. We want users to write their own reports instead of waiting for IT
6. We want happy customers
7. We want to buy this in ONE software package
8. We want to outsource all software configuration and maintenance
9. We want large monitors, aluminum cases and wireless keyboards on our PCs
10. We want to capture name and address and contact info everywhere
11. We want users to have the freedom to override business rules
12. We want a consistent high quality customer experience
13. We want the system to pick the best approach
14. We don’t want managers interfering with our work (micro-management)
15. We want easier, better scheduling with fewer disruptions
16. We want to get rid of old technology
17. We want direct access to the database
18. We want reliability, maintainability, scalability and no irritability
19. We will know it when we see it but no sooner
20. We must have everything built before release
21. We must be able to change any business rule after release, so we don’t have to figure them out now.

That’s a nice sample of a typical list – we are ignoring things like “We want the requirements to be what we wrote down in one meeting” and “We want to design the system architecture because we write the checks” and “We want this done better, faster, cheaper”. That is a different list for a different essay. Those statements are not presenting as requirements but are attempting to dictate methodology or the lack thereof.

SO – given BABOK categories that follow, what goes where? Do some statements impact multiple categories? What can you extrapolate from the above to “discover” unstated requirements?

1. Business Requirements
   1. Business Goals / Objectives
   2. Business Needs
   3. Capability Gaps
   4. Solution Approaches
   5. Solution Scope
   6. Business Case (what matters, how it matters and why it matters)
2. Requirements [STATED]
3. Requirements [ANALYZED / MODELED]
4. Business Analysis Plan
5. Solution Requirements
   1. Functional
   2. Non-Functional / Qualities
6. Transition Requirements

One “breakdown” might look like:

Arrrghh – not AGAIN! We are left to think about it until a future blog.  Doesn’t the author understand that thinking is hard?

The answer is yes – the author knows. Thinking IS hard, the brain uses more oxygen and energy than any other part of the body. People who would never think to run 50 miles actually believe that their thoughts go just as far as anyone else’s. The same folk who might admire an athlete without thinking that they should compete with the athlete have no trouble believing that they know as much about creating business solutions as a performer with an actual track record.

Are you a BA thinker, or just a participant – another talker? Are you a modeler, or just a scribe? Your ability to handle this exercise is your answer.

For those of you who do practice modeling / technical BA skill, here is a cool diagram showing ALL the requirements “types” mentioned in the BABOK. Can you use each one in a sentence?

Cool Diagram:

NEXT TIME – SYNTHESIS.

Don’t forget to leave your comments below.