Building Requirements Consensus™ for Business Process & Software Requirements
You have business process and software requirements problems?
Congratulations, you are in the right place!
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
Something is fundamentally wrong
when 45% of software "requirements”
are never used after an application is deployed.
They are not requirements now because
the functionality is not used.
It follows that they were not requirements
when they were documented!
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
The Building Requirements Consensus™ Methodology is use case based and is compatible with development methodologies like waterfall, RUP or Agile. It helps us think about the problem space and requirements of the solution more clearly. We discover, document, simulate and validate requirements more quickly using iterative methods. The result is more buy in and engagement from participants.
It is a recursive methodology that is effective at any level of abstraction. Examples include:
- top level business processes for an organization
- business processes for a department within an organization
- a detailed specific business process within the department
- the part of the specific business process to be automated
- subsystem to subsystem communication within the software requirements of the automated portion of the specific process
We use the same concepts and the same terminology across these different levels of abstraction. This goes a long way towards reducing ambiguity and misunderstandings in projects.
You do not have to change your current development practices. The Building Requirements Consensus™ Methodology works with any development methodology because the development methodology is black-box to it.
Building Requirements Consensus™ Approach
We developed a two pronged approach to address these issues.
1. Applying the Building Requirements Consensus™ Methodology
2. Using an analysts tool that supports simulation
The Building Requirements Consensus™ Methodology is 80% of the approach and using a simulation tool is 20%. You can use most of the Building Requirements Consensus™ Methodology without a simulation tool. Likewise, a simulation tool has benefits without the Building Requirements Consensus™ Methodology. For example, along with text and static diagrams, at least one tool 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 a simulation 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 is to help you become even more successful than you are today by improving the quality of your requirements. High quality software requirements are particularly important if you are outsourcing. Cook Enterprise Corporation helps ensure that your projects are more successful than average through the services we offer.
Benefits that Flow from the Goal
Imagine the savings you would experience if you could eliminate even part of the 45% of features that are never used! You would directly reduce project cost and project time by reducing unneeded functionality. You will not have to document those requirements, meet to validate them, build them or test them. You can focus on the functionality that will actually be used. Reducing functionality directly reduces cost and time.
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.
Completed projects will be measurably more successful:
- Improving bottom line by project and for the department (typically more projects completed with the same budget)
- Rising user satisfaction rating because consensus is reached among all parties involved before implementation starts and what is agreed to is more likely to be delivered
In today’s unsettled economic climate, it is extremely important to invest your improvement budget wisely. You will learn about a practical requirements approach that melds with your current development processes so you can begin to reap significant benefits right away.
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.
Our mission is to help organizations discover
where to strengthen their competitive position
by simulating business processes and software requirements,
clarifying them and building consensus,
before investing to implement them.
Let's start Building Requirements Consensus™!
- User Stories or Use Cases?
- User stories or use cases? What is the difference between them? Building Requirements Consensus maps to both equally well. You can even use them together!
- Use Case Basics from the Building Requirements Consensus™ Viewpoint
- Learn the three fundamental concepts that explain many of the use case problems you have experienced.
- Intermediate Use Case Concepts
- Use these intermediate use case concepts to deepen your understanding after you master the basics. They will improve your requirements skill. Avoid common pitfalls.
- Service Oriented Architectureand Use Cases
- Well written use cases and service oriented architecture work hand-in-glove. See how defining the problem itself as a set of services enables a SOA solution!
- Using Simulation to Add Clarity & Build Consensus
- Most people need to experience something to understand it. Once they experience it, they know what they like & don’t like. Using simulation adds clarity & builds consensus for a better result.
- A Business Analyst Who Is a SME Costs You $2 Million per Project
- Must a business analyst be a SME in a domain to be effective? Many assume yes. It turns out that that assumption is usually false. That yes can be costing you $2,000,000 - per project!
- Role UML Specification Excerpts
- These excerpts from the UML Specification document that the Building Requirements Consensus Methodology complies with this industry standard for role to replace actor. This is a technical page for tho
- Building Business Processes Consensus
- Requirements for business processes are often separated from IT system requirements. IT has highjacked the phrase: system requirements. But didn’t businesses have systems long before IT ever existed?
- Building Software Testing Consensus
- Software testing problems usually follow poor requirements. Learn how easy it is to automatically generate test scenarios from quality requirements at the push of a button.
- Outsourcing Risk and Building Outsourcing Consensus
- Reduce outsourcing risk with quality software requirements and thorough testing. Imagine what would happen if the outsourcer got complete tests upfront with the requirements?
- President's Profile
- Our president’s profile: He conceptualized the Building Requirements Consensus™ Methodology, a use case based way of discovering & documenting business processes & software application requirements.
- Testimonials from Users of Building Requirements Consensus™
- Read testimonials of users' experiences with the Building Requirements Consensus™ Methodology & Approach to add clarity & build consensus for business processes and software application requirements.
- Press Releases
- Press releases for Cook Enterprise Corporation and its Building Requirements Consensus methodology and approach.
- What's New at Building Requirements Consensus™ for Business Processes and Software Requirements
- The Process & Requirements Blog keeps you up-to-date with all additions and changes to the building-requirements-consensus.com Web site. Subscribe here.
- Services for Business Processes; Software Requirements, Testing and Outsourcing
- Describes our service offerings for business processes, software requirements, software testing and outsourcing using the Building Requirements Consensus Approach
- Contact Us About Building Requirements Consensus
- Request more information on building requirements consensus