Here’s a personal opinion: Business analysts remain one of the last bastions of antiquated technology. Put up your hands all of you only using Word and Visio. Probably only 20% of you have requirements management software, and even fewer have requirements definition tools worthy of the name. Yet everyone is under pressure to improve performance and productivity – especially now that the economic recovery is underway and project pipelines are filling rapidly. Here’s a quick primer on the Dos and Don’ts of acquiring analyst productivity software.

OK, so analysts are the proverbial shoemaker’s children, always defining requirements for the solutions of others, and never for themselves. Unfortunately, this is the cardinal rule that many analyst organizations break – they don’t properly define requirements when they look for analyst requirements definition and management solutions. Seems a little crazy doesn’t it? A quick suggestion would be to step back from the glitz of the technology for a minute and perhaps run some facilitated sessions to identify the analyst processes, the information required to support these processes – maybe even identify a few interdependencies? Sound familiar? Once you do this, the wide variety of solutions out there start rapidly falling away – and very few likely remain.

Would it surprise you to learn that there are over 100 analyst tools that are well known enough for IAG to track them? Who knew the lowly analyst had so much choice? When you evaluate tools, it is easy to get caught up in the sizzle rather than the steak. The sizzle are the flashy functionality around the system that make it more flexible in execution. The steak is the no-holds-barred answer to the question, “what was this thing principally designed to do?”

Since the sizzle is infinitely more interesting, let’s start there and talk about the kinds of sizzle you can get in an analyst tool:

Tool Integration. All tools have a degree of model sharing; upstream (to portfolio management, or project management) and downstream integration (to quality systems or development). This model sharing is either fully bi-directional (YAY!), meaning changes in one system are reflected in the other, or it is accomplished by simple export (BOO!) which can lead to all kinds of synchronization problems between repositories.

Documentation Generators. All tools are either better or worse at generating standard document templates and some are fairly configurable so that you can replicate existing internal standards for information production. More critically, these tools either capture into the repository the changes made to output (YAY!) or they force you to edit the format every time you print the same report (BOO!).

Stakeholder Collaboration. Most tools have a degree of automated collaboration to capture stakeholder commentary which is free (YAY!) but some tools force you to license the viewers and collaboration engine (BOO!). Usually, there is an auditing capability for indicating who said what, giving traceability on stakeholder review, validation and acceptance content.

Model Sharing and Global Repositories.: Tools are typically designed to be massively multi-user (YAY!) or they are primarily a single user system that can share models between users (BOO!). The difference between these are the server database options, security/access controls, check in/out controls, model sharing options and controls, etc within the system. Many systems lack the concept of a’project which I think is a bizarre oversight. A project has unique attributes like a charter, stakeholders, objectives, etc. and would include one or more use cases from an enterprise requirements repository that could easily be sharing the identical use case out to another project being worked on by another analyst. Some systems enable these concepts, many do not.

Object Relationship and Impact Assessment. Most tools enable the user to define custom object types, however the big YAY is the ease with which relationships are established (one click versus, in some cases many, many, many clicks) and the degree to which you can compare object types or look at object relationships. This type of functionality is ABSOLUTELY critical for traceability management and impact assessment. Traceability and impact assessment needs you to first establish relationships between objects (which can be cumbersome in some tools), illustrate these relationships in standard models, and be able to show how relationships are impacted under changing circumstance.

Ability to Embed Analyst Best Practices into the System. In a bizarre twist of fate, the better a tool is, the more ways it has to represent information in the system and the less usable the system is ‘off the shelf’ without some amount of training. This is a good-news, bad-news story since better quality requirements definition and management systems are highly customizable, but it could potentially spell chaos for larger teams of analysts unless some standards are set. The best tools have package configurability and the ability to embed elements of your analysts processes into the tool – meaning you can preset what objects are called, the attributes of objects and even eliminate certain options that you don’t want available to analysts in your company’s implementation of a particular tool. The purpose is to force analysts to model specific things, using specific techniques, in specific ways.

I could keep talking, but remember, these functionalities are the sizzle, not the steak. Yes, they are important functionalities, BUT, you have to first and foremost decide what analyst business processes you are trying to support – just like you’d advise your stakeholders to do. When you only focus on the sizzle – every tool has some degree of sizzle and every tool has some degree of functionality in every area above. When you get down to the steak – tools were either designed to support certain analyst processes, or they were not.

Tools tend to fall into different categories based on what they were first and fundamentally designed to do. Often, if something excels at one domain, it is poorer in other domains. You need to step back and pick one:

• End-to-End Suites. Take IBM’s Rational product line for instance, or a number of the Application Lifecycle Management (ALM) tools. Here the big difference is the scope of the software and component integration between the tools. These systems are principally designed to be end-to-end and you buy into the end-to-end concept rather than best-of-breed components. Inherently, this kind of design will have gaps. Some of these (like Rational) have requirements management (Reqpro/Doors) AND definition functionality (RRC), some are only requirements management tools. Some have the ability to manage conceptual and logical data models – others do not. Be careful.
• Requirements Visualization Tools. These popular tools (like iRise or Microfocus’ TeamDefine) are mainly designed to allow stakeholders to interact with visual models of a system. I draw these into two broad categories: ‘Visualization’ tools allow stakeholders to visually experience the process flow of an application but they’d probably want an analyst walking them through the activity to talk about the specific rules and functionality. ‘Animation’ enables stakeholders to fully interact with the system interface, and by embedding data rules behind the system, the user can also experience error conditions and alternate scenarios by operating (or animating) the system. Both classes of visualization tools have numerous vendors selling quite capable tools. Other points of evaluation are the fidelity of the models you can create.
• Requirements Modeling Tools.: There are tools like eDev’s InteGREAT (or Requirements Composer by IBM) that were principally designed for an analyst to model business requirements. Others, like RAVEN, are focused on a specific type of modeling (Use Cases) and are more ‘assistive‘ for analysts (where we’re using all meanings of ‘assist’ e.g., increase productivity, help the analyst learn, automate the production of something, and act to increase quality). The key differentiators between systems are the number of model types created, the model fidelity, number of domains of knowledge that can be created or managed – some only allow the modeling of process knowledge, others can model any number of dimensions of knowledge (Process, data, rules, issues, interdependencies/interfaces, training, etc) and the degree of knowledge transformation (given a text description will the system create graphical description and vice versa) or given a use case model and clear actors, can the system render a cross-functional swim lane diagram.
• UML Modeling Tools. These deserve a special mention since the UML can be used to generate a rich model of a business process and identify/manage requirements. The upside to these tools is often the ability to forward and reverse engineer code or to model enterprise architecture. The downside is that you are locked to the UML and this modeling standard’s ability to resonate with business stakeholders that are not trained in the UML. The big differentiators here are very numerous since UML tools also get used across the entire application life cycle.

If you go beyond the above four areas there is also a whole series of tools from other domains like quality (HP’s Quality Center), Enterprise Architecture (Casewise), Business Process Management (IDS Scheer), process logic capture tools (StereoLOGIC), among others that are converging to better service the needs of business analysts.

The landscape is filled with productivity tools that are well designed to make analyst teams more productive. IAG has itself implemented or used most of the ones I’ve named here and we are resellers of more than six of them so I’ll not stand up and endorse one vision over another. The key is to recognize that there are choices – a huge number of them – and take the time to do the requirements analysis properly before selecting and implementing a system. As ironic as it sounds, it seems that lousy requirements definition is pervasive when looking at requirements definition and management tools. Use the purchase of a tool to figure out your analyst processes and to strengthen consistency. Don’t be the shoemaker’s child any longer.

Click Here for more Business Analysis Resources

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.