As a BA, one of the central guiding principles for me has always been, "If it isn't going to make a difference to the outcome, don't do it." Yet I see a lot of confusion amongst BAs about how much analysis to do on a given project. Are structural models (class diagrams and ERDs) always worth doing or are they a waste of time? How much detail should you put into the user requirements? Obviously, blindly creating documentation without understanding its value - or if it even has any value - is not useful. The problem is when to do what. I thought this would be the perfect forum to toss out the question: How much analysis do you really need to do? I invite all responses – pro and con, cool and heated.

My real aim here is to generate discussion, not to be proscriptive. To get the discussion started, I'll start with some general guidance I’ve found useful.

The degree of documentation and analysis required for a project depends on a number of factors, including the lifecycle approach being used on the project, the size of the project, the type of solution being contemplated (in-house or vendor solution), and the risk involved.

There are two broad categories of lifecycles used on projects: definitive lifecycles - which are well-defined processes – and empirical processes, which are less defined. Projects managed using definitive lifecycles will require more documentation; those using en empirical lifecycle will require less. For example, while in a definitive lifecycle you might produce complete user requirements – expressed, for example, as use-case specifications, with an empirical lifecycle this would be of little value, since the requirements are constantly in a state of flux. On the other hand, even on an empirical project, there is still a need to list (if not completely describe) user tasks (use-cases) early on so that the effort required for and cost of the project can be estimated.

With respect to size – the larger the project, the greater the need for documentation. The team is bigger, the problem is more complex and more dollars are at stake – all factors favouring heavy documentation.

Solution type is another important factor. In-house solutions favour more documentation; vendor-supplied off-the-shelf solutions favour less documentation. Business rules and requirements that are standard across an industry are more likely to be supported in an off-the-shelf solution – and, therefore represent less risk than requirements that are peculiar to a business area. Naturally, more effort and detail will go into documenting the high-risk requirements.

I’ve tried to summarize some of this in a table that looks at UML tool usage for projects based on their size, solution type and lifecycle approach. In the table, a ‘small’ project is one that has a short timeline and budget and does not involve a change to a business process; an example is a change to an existing screen, or the addition of a new query screen to an existing system. An example of a large project , on the other hand, is the introduction of a new business product or service. The notes in the last column of the table relate to new UML artifacts; however, where there are existing UML artifacts related to the problem, they should be reviewed, and amended as required. The table can be applied to non-UML projects simply by replacing the UML terms in the last column as follows:

• ‘Business process models’ – instead of ‘business use cases’
• ‘User requirements/ user tasks’ – instead of ‘system use cases’
• ‘Statechart diagrams ‘– instead of ‘state-machine diagrams’
• ‘Data models/ERDs ‘– instead of ‘class diagrams’

Tailoring UML tools usage to the project:

Project Size: Small

¹ Agile projects may use ‘user stories’ as an alternative to use cases.

Project Size: Large

 

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: Complete (or use a non-UML alternative) in order to capture end-to-end business process workflow. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping. Class diagrams: Complete. Classes, relationships and numerical rules (multiplicities) are required for across-the-board business rules. State-machine diagrams: Use to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
In-house development	Definitive	Business use cases: Complete. System Use Cases: Complete Class diagrams: Complete Activity diagrams: Use to describe workflow of business use cases (business processes) and as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	Empirical	Business use cases (or a non-UML alternative): For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. State-machine diagrams: Create in order to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
Off-The-Shelf	Definitive	Business use cases: For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. Activity diagrams: Use to describe workflow of business use cases (business processes) focusing on processes that are non-standard in the industry. Use activity diagrams as an addendum for system use cases whose flows connect in complex ways.

Finally, keep in mind that we’re talking here only about the artifacts that are created for each project. Some of these will be directed to business stakeholders and some will only be distributed to other team members and solution providers. But that’s a topic for another column (and one that I address on a tool-by-tool basis in my book, The Business Analyst’s Handbook’).

In the meantime, I’m looking forward to having others weigh in on today’s question “How much analysis do you really need to do?”

Howard Podeswa
For more on this topic, please see The Business Analyst's Handbook and the upcoming release of UML for the IT Business Analyst, 2nd Edition