Would you buy a car from a dealer who gives you only a written description? Or who presents text plus engineering diagrams?

Of course not! Yet that is precisely what we expect other people to do!

You cannot tell how a car will feel and perform from text or diagrams; people cannot tell how a business process or software application will feel and perform from them either.

A root cause of pervasive requirements problems are the mediums historically used to document requirements, namely text and diagrams. Adding simulation of requirements before building reduces risk and cost by adding clarity and building consensus as people engage via text, diagrams plus simulations.

The statistics are staggering: Click here to view sources.

1. 45% of all software features are never used and only 20% are always or often used. - Jim Johnson, Chairman, Standish Group

2. 68% of companies (those ranking in the bottom two-thirds in business analysis skills and requirements practices) are more likely to have a marginal project or outright failure than a success. In fact, half of their projects are runaways which had any two of:
- taking over 180% of target time to deliver
- consuming in excess of 160% of estimated budget
- delivering under 70% of the target functionality

3. A company using poor software requirements practices (i.e., ranking in the bottom two-thirds in business analysis skills and requirements practices) compared to a company using the best requirement practices (ranking in the top third) pays an average $2.24 million penalty per project! (Average project size was originally budgeted at $3 million. This is a significant number - 75% of budget!). See IAG’s 2008 Business Analysis Benchmark for #2 & #3.

4. 91% of business analysts use a tool that is not designed for requirements definition or integration with automated test tools, The Role of the Business Analyst, voke media, 2008. See the Typical Situation diagram below for the results of using ineffective analysis tools.

Answer these nine yes or no questions to help you determine whether your organization ranks in the bottom third, middle third or top third in business analysis skills for business process and software requirements practices.

Building Requirements Consensus™ Methodology

Building Requirements Consensus™ Approach

Cook Enterprise Corporation is a Blueprint Business Partner. Blueprint™ was Gartner's 2008 Cool Vendor in Application Development in the business analyst space. In 2009, Blueprint™ won a prestigious Jolt Product Excellence Award in the highly competitive Design Tools and Modeling category. (Jolt Awards are the Oscars of the software industry.)

The Building Requirements Consensus™ Methodology is 80% of the approach and Requirements Center is 20%. You can use most of the Building Requirements Consensus™ Methodology without Requirements Center. Likewise, Requirements Center has benefits without the Building Requirements Consensus™ Methodology. For example, along with text and static diagrams, Requirements Center simulates requirements and automatically generates test scenarios before a business process is implemented or code is written.

However, the combination of the Building Requirements Consensus™ Methodology plus the Requirements Center tool is an unparalleled effective approach to getting accurate and unambiguous business process requirements and software requirements. The methodology provides the framework for how to think about the problem; the tool supports what applying the methodology accomplishes and adds simulation and automatically generates test scenarios.

Simulation is important. Why? Because most people need to experience something to understand it.

You will never know what a piece of chocolate cake tastes like by looking at a picture of it - no matter how many pixels it has!

Simulation also helps address the 45% of unused functionality (see chart above). It makes them easily understood, discussed and removed. Now only the slimmed down process or software requirements need to be analyzed, built and tested.

Every removed "phantom requirement" directly reduces bottom line cost by reducing the amount of work in the project.

Our Goal

Benefits that Flow from the Goal

The Building Requirements Consensus™ Approach will help you identify those phantom “requirements” by making the software requirements more accessible to the whole project audience up front. The proposed requirements are understandable making it less likely that functionality that will never be used is approved.

We present the same software requirements in the right format for the audience member. For many people that is a simulation. Think of playing a video game as opposed to either piecing together hundreds of pages of text or digesting multiple technical drawings.

Another example is that sometimes your organization's improvement means discovering and killing a bad project early thereby freeing the time, resources and money that would have been spent on the bad project on a better project.

Metrics

Invitation

We invite you to explore this site. Please let me know what you think, what you like, what could be improved or what you would like to see added. We appreciate the time you are investing in learning how to improve your requirements to strengthen your organization.