Resources for Business Analysts

I promised you more information on the game. I am working on an article, but here is some partial feedback.

One of the purposes for the game was to find out what the problems are in the industry. The point was not to get ideas for products, but to find out what problems the products were solving.

Some of the product descriptions I received were pretty far out there technically. Given enough time and money, they could maybe be created in a few years (anyone have a few spare million around to experiment with?) That’s OK. They told me what hurts, and that was the point.

So here I will summarize for you the products and problems we uncovered with the game. And you can participate in the followup survey. Post a comment telling me which (if any) of the products or problems apply to you or the company you work for. Then, tell me how important it is for you to solve the problem by assigning a dollar value. How much would you be willing to spend to buy such a product?

$10, $50, $100, $500, $1000, more than $1000.

(I could just use a 1-5 scale, but I have found in the past that the results are pretty meaningless. It has to do with the fact that each individual person has a different definition of average.)

====================================================
So post a comment by April 6, 2007 at midnight EDT - the name of the product you want or need, and what you would be willing to spend to have it. You can list more than one product in your comment.
====================================================

Don’t worry about whether or not the product is technically feasible. We are exploring where the problems are in the industry and how big the problems are.

Products
======

Smart Pretty Printer for Use Cases
———————————————————————

Give the tool some text and it does its best to format the use case. Every sentence is numbered, compound sentences are broken in two, verbs are changed to active form, and sentences are rearranged into subject predicate object format. Anything the tool can not figure out is highlighted for a BA to review and fix. The output is a use case that is formatted according to a consistent, easy-to-read standard.

Problems that it solves: Removes the tedious nature of writing use cases. Presents use cases in a common structure and format, making them easier to review. Smooths out the differences in writing abilities among a team of analysts.

Template Use Cases for Insurance (same idea could be done for many industries)
———————————————————————

The product consists of a set of Microsoft Word documents that contain use cases common to the insurance industry; sample interview questions for stakeholders to elicit information needed to refine the use cases for a specific project; use case diagrams, activity diagrams, and class diagrams for all the use cases and domain model in XML format.

Problems that it solves: Decreases project time by providing a set of common business processes for an industry. Shortens the requirements definition phase of a project. Increases the possibility that project requirements will be complete and correct.

Holistic View of Requirements
———————————————————————

The tool inputs all of the various project requirements, such as goals and objectives, business requirements, business rules, supplementary requirements, user interaction design, process flows, data dictionaries, glossary, miscellaneous artifacts, and the relationships between all these parts. It then formats them into a whole view of the problem. This allows the project team to demonstrate to stakeholders, just what it is that the project is trying to solve, what is needed to solve it, and how the solution will be broken into its technology, process and organizational change elements. It allows the team to quickly move one element of an event flow from process change to technology, get an estimate from technology and make a better decision on cost versus benefit. It allows the team to model a process and visualize which parts are manual, which parts are automated, and flip these with a mere drag and drop.

Another feature is the ability to turn the system from black box to white box, allowing the team to see the different levels of the system from requirements to design to implementation. The white-box view can be output to update application and business architectures.

Problems that it solves: Better ability to communicate between business and technical team members. Ability to visualize all requirements and their relationships. Ability to see the impact of change on the system. Ability to see the relative merits of technology vs process.

Cohesive Requirements Tool
———————————————————————

This tool is capable of capturing multiple types of Requirements artifacts and integrating them to produce a cohesive and non-redundant definition of all the Requirements.

Problems that it solves: Consistency among different requirements sources.

B2S (Business-To-Software)
———————————————————————

This software allows business people to input their requirements by voice, keyboard, scanning, or any other input devices. It interacts with the person to collect their thoughts, wishes, business rules, vision and any other requirements.

The software facilitates global internet interactive sessions by listening to business users talk and gleaning all of the requirements from the speech. It’s facilitator module can prompt the participants at the right times with meaningful insights and questions for the domain.

The analyzer module interprets all that seemingly random input and makes sense of it using a form of artificial intelligence, a new kind of neural-2-neural network learning and analyzing system, that was adapted from some original software for detecting fraud.

The output of the software is requirements in a form ready for the programmers to use to produce code.

The software also manages and organizes the requirements, making it easy for business users to review and update the requirements.

Problems that it solves: Less time and effort spent to elicit, organize, specify, manage, look after and care for all of the requirements for a new product or system. Better communication with programmers. Removes dependence on unskilled requirements analysts. Better requirements documents.