The Modern Analyst Blog for Business Analysts

Howard Podeswa
Howard Podeswa

How much analysis do you really need to do?

"Pull and Turn" by Howard Podeswa - from the Object-Oriented Painting ShowAs 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

This entry was published on May 03, 2009 / Howard Podeswa. Posted in Business Analysis, Tools. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  0 members liked this article

Related Articles

COMMENTS

Adrian M. posted on Sunday, May 3, 2009 5:43 PM
If you haven't noticed, the image at the beginning of this post is a painting by Howard Podeswa titled "Pull and Turn" which was showcased as part of the OOP - Object Oriented Painting Show.

That's very cool Howard!

- Adrian
Adrian M.
DougGtheBA posted on Sunday, May 3, 2009 6:13 PM
Howard.

Excellent topic to ponder and well worth bringing up. I would certainly agree with everything you mentioned regarding project and solution type. It is easy to fall into the rut of producing documentation just to produce it. This can be a colossal waste of all types of resources and may end-up as throw away work. Analysts definitely need to think about what the value is to producing an artifact and question the need for it just like they would question a valueless aspect of a project.

I'd also like to bring up another factor that is important to this topic. Organizational Environments are also a major component when considering what to document and what the value of it is. For instance, a firm that is in the beginning of CMMi maturation will find much more value from some artifacts than one at Level 3 or 4? This is due to the fact that the early stages of CMMi implementation involve a solidification of processes in order to get to the point that they are correct and repeatable. If the example firm was previously jumping from Requirements to Construction without Design, the value obtained from a Logical Design document and associated modeling is huge and provides great value. Equally important is the routine that is performed in order to create the documentation, which is the actual maturation of the individuals learning to execute better.

Conversely, the Level 3/4 organization has, in effect, trained itself to always follow procedure and process and knows that it ALWAYS creates this or that document. This is a point in which the personnel that do so must ask themselves if there is still inherent value in the routine. Afterall, the learning curve is no longer and if there is no other benefit from a procedural step and its document, then perhaps it should be eliminated or tailored to include only those parts that do provide value.

Thanks for the opportunity to weigh in.

DougGtheBA
DougGtheBA
steve posted on Monday, May 4, 2009 11:36 AM
At the bare minimum, the business analyst needs to do enough analysis in the problem domain to determine the conditions that are causing the business problem to be solved. This can best be done with diagrams or models, UML or otherwise. Workflow diagrams and models seem to be a preference among business analysts documenting the problem domain. It is from the definition of the conditions causing the problem that we can determine the solution and then the requirements to implement the solution. Since by definition a problem must have more than one solution (or it's not a problem) the solution domain analysis focuses on eliminating alternate solutions until the best alternative can be selected. Again, it is usually easier to use a diagram to visually compare various solutions.
When the business has provides a solution without specifying a problem and demands that solution be implemented as stated within a certain time frame, analysis becomes a luxury, and could expose the fact that the business' solution is not the best or that the business has not defined the right problem. This is what the business analyst is supposed to do, but the political fallout might not be pleasant.
steve
Adriana Beal posted on Monday, May 4, 2009 4:06 PM
Howard,

I think it would be a good idea to discuss separately "suggested UML tools based on project size, solution type and lifecycle approach" and "how much analysis is needed on a given project".

In regard to the second topic, I would say that the level of experience and competence of the development team is something that can also significantly affect the amount of analysis that a BA needs to perform during a project. I've seen relatively simpler projects require much more detailed analysis and documentation only because the developer wasn't experienced enough.

For example, if I'm specifying a web application that will be used to exchange messages among people from different countries that will be developed by skilled IT professionals that I know are familiar with software internationalization, the level of documentation I'd provide on character handling would be minimum, whereas for a less experienced developer I would produce a much more detailed specification to prevent the application generating subject lines such as "???? ????? ?? ????" due to character enconding issues).
Adriana Beal
Nathan Caswell posted on Tuesday, May 5, 2009 3:10 PM
DougG makes a very good point wrt maturity.

In a high maturity organization, most of the documentation is, in principle, already there.

While there are high maturity development organizations, every development project seems to be directed only toward that development. Once done, there is no place for the documentation to go.

Even in small businesses it isn't clear there should be an 'empirical' class project. Small projects should start from the existing system and result in incremental substitutions or additions to the overall business system and documentation.

The real life situation is that even large projects can go forward with their own top level system view generated for the purposes of that project. War story: I've seen a large effort where two projects made major investments in process capture/modeling that overlapped for 20-30% of the functionality. They captured totally different processes, everyone knew it, and because there was separate funding no one cared.
In the end, users kept post it notes as they maneuvered between systems.

So, the question of what documentation to generate is really:
o what is required to gain customer "start" approval and acceptance criteria
o what is required to pass QC
o what is enough that the next level doesn't come back with too many questions

Feeling cynical today i guess.
Nathan Caswell
Nathan Caswell posted on Tuesday, May 5, 2009 3:23 PM
The level of documentation to move between levels should be independent of the person at the other end.

At each hand off, there has to be an external/internal interface where the external input only specified the external behavior and the internal work uses its resources to accomplish that.

In the messaging example, "all textual data storage or processing shall support international encodings" should be sufficient. It is a good thing to walk down the hall and help the new guy out. But it isn't a good thing to muddle resource quirks into the specification documents.
Nathan Caswell
Adriana Beal posted on Wednesday, May 6, 2009 7:22 AM
apthrop said, "In the messaging example, "all textual data storage or processing shall support international encodings" should be sufficient. It is a good thing to walk down the hall and help the new guy out. But it isn't a good thing to muddle resource quirks into the specification documents."

In an ideal world, apthrop, I'd agree with you that a high-level requirement statement should be enough (and usually is for a more seasoned team, who can always come back with questions as to what your requirement really means).

If using a less experienced team, however, the way you stated the requirement would cause unnecessary development effort and code complexity because "all textual data storage or processing" would be too encompassing (in reality some processing and some data would require that, not all.

In my opinion the level of detail to be provided in the documentation has to take into account the level of detail the implementation team needs to be able to translate the functional spec into software that behaves correctly and does not suffer from "feature bloat". And this requires understanding the audience that will use your documentation.




Adriana Beal
Howard Podeswa posted on Wednesday, May 6, 2009 9:04 AM
Thanks to MA-ers out there who have responded so far. As I had hoped - the initial post has generated a lot of important discussion on this issue - and have pointed to a number of parameters to look at beyond those I had begun with. Here's my summary of what was brought up in comments:
- Maturity of the organization: with more documentation effort required for less-mature orgs (because less is there initially)
- Level of competence and maturity of the development team - with more documentation required for less competent teams. Some of the competence revolves around the team's business knowledge as well as technical (as in the internationalization example)
- Project timeframe - with less analysis on shorter timeframes due to time constraints (and possibly - politics [for better or worse])
- Reality check - how much does the customer and QA need for sign-off; how much do the developers really need.

Let me know if these conclusions sound reasonable. There is still time to add more comments and have these considered in the revisions I am currently making to my book, UML for the IT Business Analyst. Thanks will go in writing to the MA community for their input and to some of the individuals who have contributed comments.
Howard Podeswa
Tony Markos posted on Thursday, May 21, 2009 2:27 PM
How much do we need to model?

We need to model the essential. And as function is defined by its inputs and outputs, it is essential that we model the inputs and outputs in functional definition (i.e., fuctional requirements specification).

Until we start talking about inputs and outputs (i.e, move away from the UML and BPM techniques) there can be no answer to the question.

Tony
Tony Markos
Craig Brown posted on Wednesday, October 7, 2009 7:03 AM
What about the idea of pull and push on workflow. At first pass the requirements only need to be sufficient to estimate he project and do the initial architecture. This is a pull from the project sponsor (who is paying) and the solution deisgner (who has to scope the technical work.)

Later you can deliver just enough to get the developer/designer to be able to do the work to your satisfaction (or to meet your test cases.)

If you are on the team throughout the development phase you can err on the side of light documentation - becasue you are there to ask, and you can elaborate in a Just In Time fashion. If you won't be around you need to be much more comprehensive.

Craig Brown
Nathan Caswell posted on Wednesday, October 7, 2009 7:52 AM
Craig,

Excellent point. Large project methodology is going to have phase gates of some sort. Given the UML emphasis here RUP is a canonical example.

A point to question is if there is any use for documentation after the project is complete. Agile takes the position that the code is the documentation, so any future executive who wants to know how their operations run can just read the code. Others think there is value in having clear articulation of the business strategy and business operational architecture as well as IT architecture and application design. The major arguments for the latter position is 1) that it becomes progressively more difficult to 'just fix this one thing' in the presence of the slag heap of previously 'just this one thing' local fixes, 2) that overall system validation becomes increasingly difficult, and 3) business adaptability at larger than 'just this one thing' is seriously compromised, leading to 'start over' solutions in favor of much lower cost incremental improvements.
Nathan Caswell
mark1213 posted on Thursday, March 19, 2015 1:52 AM
The whole thing is explained in quite an easy manner. Looks very easy to understand A number of useful things are mentioned to improve all the business analytic.Looks very helpful to me as well.

http://www.itinterns.org/
mark1213
Only registered users may post comments.

 



Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts.




 

ModernAnalyst.com LinkedIn Group ModernAnalyst.com on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Copyright 2006-2024 by Modern Analyst Media LLC