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
| Solution type |
Lifecycle |
UML tools |
| In-house development |
Empirical |
- Business use cases: May be skipped, as no changes made to business process.
- 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.[1]
- Class diagrams: Model new classes and relationships to discover structural business rules; may be skipped if problem well-understood.
- State-machine diagrams: May be skipped.
- Activity diagrams: May be skipped.
|
| In-house development |
Definitive |
- Business use cases: May be skipped, as no changes to business process..
- System Use Cases: Complete
- Class diagrams: May be skipped if a simple change, such as query screen. However, if new business concepts introduced, model them and their relationships in order to discover structural business rules.
- State-machine diagrams: May be skipped
- Activity diagrams: Use as addendum for system use cases whose flows connect in complex ways.
|
| Off-The-Shelf |
All lifecycles |
- Business use cases: May be skipped, as no changes to business process.
- 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 new classes and relationships to discover structural business rules – focusing on business objects and rules that must be complied with but are not standard in the industry. (This step may be skipped when the problem is well understood and the rules are standardized.)
- State-machine diagrams: May be skipped.
- Activity diagrams: May be skipped.
|
1 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