Why, What, When, Who, How, and Where? by Gary Rush, IAF CPF
I’ve been in the IT industry for 40 years and I’ve watched methods come and go but it has been a lot of re-engineering of the same. From Structured Analysis, Information Engineering, Agile, etc., the IT industry has been looking for the “right” answer on “how to” develop solutions. We’ve had it all along, but we get too wrapped up in the jargon and in the latest fad. The Why, What, When, Who, How, and Where? still need to be answered to develop quality requirements. Analysis and design can answer those six questions – how you get there varies.
Analysis – Why, What, and When?
Why?
“Why?” does the business exist? Why does this process exist? These questions set the context of the work. This question is often neglected and organizations sometimes re-engineer a process that, if asked why it exists, should not exist in the first place. There are many tools to capture the answer to, “Why?”. Context Diagrams, Purpose Statements, and even a narrative answer are effective and work.
What?
“What?” is the classical “logical” analysis defined in Structured Analysis – separating “What” from “How”. What defines what must happen, what data must be captured and used, and what rules must be followed – irrespective of how it is implemented. Defining the “what” of a business is important. “What” doesn’t change often – it’s very stable. For example, what accounts payable does has been the same for decades – the change comes in “how” it is implemented. Process Models, Use Cases, Conceptual and Logical Data Models all help define “What”.
When?
“When?” is important to know when actions occur in a business or process. “When?” guides process and data needs in an organization. “When” speaks to Business Rules, Decision logic, and timing for processes. “When” doesn’t change when implemented.
Design – Who, How, and Where?
Who?
When you move into design, you are moving from a pure environment to one of reality. You first need to know “who” is involved. Who is the user? Who is the customer? These answers help define a flow and sequence of a business. We don’t talk about the “who” in analysis because it can change in implementation. Expanded Use Cases, User Stories, Dependency Diagrams, Work Flow Diagrams, all help define “Who”.
How?
Now, we need to know “how” a business or process will work in the real world – with media, exceptions, people, etc. This includes understanding the supporting technology and architecture as they directly influence “how” the process will work. Prototyping, Work Flow Diagrams, User Stories, etc., all help define “How”.
Where?
“Where?” is the place or location in which a process gets used. Will it be at a desk? Will it work in a production line? These questions help define the appropriate technology. Again, Prototyping, Work Flow Diagrams, User Stories, etc., help define “Where”.
The Biggest Problems
The biggest problems are never the methods used. The biggest problems are:
- Choosing a method that gets you suitable solutions. Too often, organizations select a method and neglect to include important elements – this has happened with Agile. They develop solutions, but skip the analysis. Quick, iterative, etc., are all great, when analysis is included, but skipping important elements is not a good strategy.
- Getting business engagement has plagued IT for decades. The solution is simple – use facilitated workshops/meetings to develop the analysis and design artifacts. It reduces time (taking 1/4th the amount of time on average), increases quality, increases engagement, and the engagement allows business to take ownership of the artifacts.
So…
Which method is best? My answer is, “The one you actually use.” Many methods help you get to a suitable solution, so pick one you are comfortable with and use it. You can manage a project using numerous strategies, Waterfall, Agile, RAD, etc., all work. Looking for the “right” method misses the point. If you can answer the Why? What? When? Who? How? and Where? questions, you have selected methods that work. Finally, use facilitated workshops/meetings to develop all of the analysis and design artifacts. My advice – Keep it simple – understand the underlying concepts and the answers become obvious. 
