Monday, 27 September 2010 15:14

The 1-2-3 of Business Analysis

Written by Keith Barrett

Business Analyst 123 Writing requirements is like writing a story in that our goal is to convey information in such a way that everyone who reads the story can clearly understand and visualize the unfolding events, overall plot, and ultimate ending. From a requirements standpoint, there are three distinct aspects to writing the story and these make up the 1-2-3 of Business Analysis.

1. Author

To write the story we have to consider the many different techniques available to the analyst today, for example: textual requirements, process diagrams, use cases, screen mockups, etc. Each of these provides a different view into the story and gives the Analyst options on how they depict the story. Selecting the appropriate techniques starts the process and is dependent on several factors, not the least of which is methodology - agile, waterfall, or some mix. Once we start authoring the selected techniques, we then need to maintain a strong connection across these techniques, better known in the industry as traceability. We maintain traceability so that throughout the process we can assess the impact of making changes and confirm, from a coverage standpoint, that requirements are being decomposed to lower and lower levels of detail. We refer to this as being expressive in authoring your requirements.

As the industry has matured we've learned that merely managing the chaos of change across a list of textual requirements just isn't sufficient. It will stem the bleeding but not bring healing. To truly heal the requirement process we need to merge all these different techniques during the authoring phase so that a single story emerges. We do this by understanding how these techniques all complement each other. For example, textual requirements are often used to describe different categories of requirements like business needs, user tasks, and functional system-level behavior, which may cause us to create a process diagram that depicts a high-level business process and/or lead us to create a use case that depicts the specific sequence of events that a user goes through to accomplish a given goal against the system. The behavior described in the use cases may drive us to create screens that get mocked up to help show the visual element of the user experience.

Although authoring these different techniques and connecting everything together is possible with traditional tools, like MS Office, it's an extremely high amount of effort. Leveraging something like Requirement Center enables all of these techniques to be authored and connected within one product and drastically reduces the effort required to author the requirements story.

2. Validate

Validation is all about asking someone, either upstream business users/stakeholders or downstream IT resources, whether or not the requirement story is correct and complete. The only way requirement quality can be improved is through highly iterative validation/review sessions in which we share what has been authored to date while asking for feedback on the level of accuracy and completeness of it. The challenge today is that how we conduct our review sessions is hindering our ability to receive good quality feedback. We're either walking through documents that are so mind numbingly full of content that nobody can actually see and understand the story we're trying to tell, or we're showing a prototype that navigates through a series of screens but is still disconnected from the real behavior we described in the use cases. Sometimes a mix of both approaches is used. These approaches are like handing someone a dictionary and asking them if we have the requirements right...all the pieces are in it but because of how they're arranged it's impossible to figure out what the requirements story really is.

Because this process is so painful for the reviewers, the end result is almost always a rubber stamp of approval so that the process can continue. Most business stakeholders have just accepted the reality that it will take several iterations of actual product releases before the system really does what they need it to do. Which is why the industry statistics haven't changed in decades - 40% of IT's budget is being consumed as a result of poor requirements.

Validation has to change from painful, long, infrequent review sessions that conclude with rubber stamps, to enjoyable, quick, and frequent sessions that provide quality improving feedback. Going visual is the only way to do this. But here's the rub, going visual doesn't mean just showing them a prototype of screens, as prototyping is only a piece of the overall story. We have to tell the story in a cohesive and contextually rich way that makes it easy for a reviewer to wrap his or her mind around the story and truly validate whether it's correct and complete. This is why Blueprint is pushing the industry towards real requirement based simulations that indeed encompass all our different techniques and, for the first time, allow users to quickly and easily "get it" so they can provide the feedback we need. The simulation must merge the behavioral requirements (typically authored in use cases) with the upstream textual requirements for business needs/rules and downstream screen designs for the user experience. Take any of these out of the simulation and the story is anemic.

3. Communicate

At some point, as we go through the iterative process of authoring and validating the requirements story, we'll need to communicate this information to a variety of audiences. Communicating is different than validating in that we're not asking for feedback... it's more like telling someone the story instead of asking for feedback on the story. We often need to historically document how things looked at a certain point in time or we need to provide documents that can be officially signed-off on or we simply need a list of items to facilitate a prioritization session, etc.

Needless to say, when our primary authoring environment is the document, we end up creating documents that are easy to manage and terrible for consumption...think dictionary. Instead we need to be able to produce documentation in a variety of formats, catered to the specific needs of a given audience, whether it be a Word document, Excel spreadsheet, or HTML site. We need to communicate just the right amount of information, in just the right way, to just the right people. This is why using a template based document generation process from a tool is always better than handing someone version x of the document I've been using to manage my requirements with.

Although these generated outputs can be utilized as part of the validation process, and are a step forward from handing them a document used to manage requirements, ultimately even generated documents that are highly catered to a given audience still fall short in their ability to convey the story well enough to get the feedback we desire. As such, documents should primarily be used as reference points and sign-off mechanisms while other techniques like requirement simulations are used to drive validation and review sessions.

The Net-Net of it all

Getting requirements right requires an integrated approach to Authoring, Validating, and Communicating the requirements story throughout the requirements lifecycle. This is no longer a pipe dream or just a theoretical conversation.

Don't forget to leave your comments below

Keith Barrett is a 20-year veteran of the software development industry and is currently a Senior Sales Engineer for Blueprint Systems. He also co-hosts the Requirements Unplugged podcast series on the site. For further information, please visit


© BA 2020

macgregor logo white web