In one of my recent blog articles, Risk Management: Business Analysis is a Huge Risk for Most Organizations, I stated that business analysis is at a dangerously low level of maturity for most organizations as evidenced by Standish Group Research, which analyzes project performance.  Standish Group Research shows that the top five reasons for failed or challenged projects are:

1. Lack of user involvement
2. Lack of transparency
3. Poor or incomplete requirements
4. Changing requirements
5. Lack of business alignment

Now, examine these problems carefully; all of them are related to poor business analysis.  Looking at this and other research, I firmly believe that poor business analysis is the number one cause of failed and challenged projects. According to the Business Analysis Body of Knowledge (BABOK), business analysis involves much more than just writing solution requirements. However, in many organizations, BAs only write solution requirements and do not perform other key activities specified in BABOK. For example, few business analysts are actually involved in Enterprise Analysis and Solution Assessment and Validation which are two key knowledge areas specified in the BABOK.

Many people think that Requirements Analysis and business analysis are one in the same. Requirements Analysis is only one of the six knowledge areas in BABOK. It’s important to stress that there is much more to business analysis than just writing solution requirements.

Many confuse requirements engineering and business analysis, thinking they are one in the same; however, they are not. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Requirements engineering might address problems 3 and 4 of the Standish Group problem list, but would do little for 1, 2 and 5. Let’s explore the differences between the two.

Requirements Engineering (RE)

Requirements engineering is a systems and software engineering process which covers all of the activities involved in discovering, documenting, and maintaining a set of requirements for a computer-based system. The first use of the term ‘requirements engineering’ was probably in 1979 in a TRW technical report, but the term did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial and establishment of a conference series on requirements engineering.  Requirements engineering is often very rigid and engineering-focused as it originated from the IEEE world.  The focus is clearly on developing engineering specifications for a product and not delivering business value in an environment that must address people, process, and technology. With the rapid adoption of agile development practices, some industry observers have questioned if requirements engineering is still relevant as it is a process for software engineering, which agile has mostly replaced.

Requirements engineering is primarily focused on building products and does not include many of the other activities involved in business analysis such as business process improvements, building a business case, or delivering business benefits. Basic traits for requirements engineering include:

• Solutions are engineering-driven and focused on delivery of product features, not business benefits.
• Requirement engineering typically deals with large complex systems in which software is only a component (e.g., airplanes, naval vessels, hydroelectric plants, etc.).
• Two primary requirements engineering activities:
• Requirements development.
• Requirements management.
• Requirements are related to products, not processes.
• Requirements engineering addresses only Functional and Non-Functional requirements while ignoring Business, Stakeholder, and Transition Requirements.
• Requirements engineering does not work well for agile development practices where lighter requirement practices are used (user stories) and focus is placed on collaboration and less on rigid engineering practices.

Business Analysis (BA)

Business analysis is much broader than requirements engineering. The focus of business analysis is to deliver solutions that improve business outcomes. Software is usually one part of the solution. Business analysis also addresses people and process issues in addition to technology. Below is a list of BA characteristics:

• Solutions are business driven and aligned with business needs.
• Business analysis is used for enterprise projects where people, process, and technology issues must be addressed.
• Four primary requirement activities:

1. Elicitation.
2. Requirements development.
3. Requirements management.
4. Requirements communication.

• Solutions are focused on using technology to help people performing business processes.
• Solutions are often purchased instead of built (ERP Systems, Cloud Applications).
• Addressing organizational change and business process change is critical for successful business analysis.
• Business analysis involves facilitating business change.
• Delivering business value and ROI are expected.
• There are five types of requirements: Business, Stakeholder, Functional, Non-Functional, and Transition.

Selecting a Business Analysis Tool

I have worked with many organizations that simply do not understand the difference between a business analysis tool and a requirements management tool. The vast majority of requirements management tools on the market support requirements engineering and provide little or no support for business analysis. A requirements management tool can work very well for defining and managing requirements for a product.  However, the product that is built may not deliver any business value or may not help users perform their activities because the requirements tool used only allows for defining Functional and Non-Functional Requirements and does not allow for capturing business and stakeholder requirements. If your goal is to deliver business outcomes and help users better perform their daily activities, then chose a business analysis tool and not a requirements management tool.

At present, Enfocus Requirement Suite™ is the only true business analysis tool on the market. If you are in a Corporate IT department and you are selecting a tool for product requirements, you are probably selecting the wrong tool. IT departments deliver services and do not usually develop products. If you are looking at tools and see taglines such as the ones below, be careful to ensure that you are choosing the right tool for your needs.

• Requirements Definition and Management Software
• A Better Way to Manage Requirements and Deliver the Right Products
• Software for Managing Requirements
• A Tool for Managing Product Requirements

A business analysis tool includes many capabilities beyond just requirements.  Below are distinguishing characteristics of business analysis tools:

• Addresses all knowledge areas in IIBA’s BABOK:

1. Business Analysis Planning and Monitoring
2. Elicitation
3. Requirements Analysis
4. Requirements Management and Communication
5. Enterprise Analysis
6. Solution Assessment and Validation

• Captures all five types of requirements as defined by the IIBA (Business, Stakeholder, Functional, Non-functional, and Transition).
• Focuses more on customer collaboration over rigid engineering specifications.
• Can define the business case within the tool.
• Addresses people, processes, and technology, not just technical specifications.
• Can trace requirements to needed business processes changes, IT services and organizational change initiatives.
• Provides a stakeholder impact assessment capability within the tool.
• Captures stakeholder needs separate from requirements with full traceability from requirements to stakeholder needs.
• Can define the problem statement within the tool.
• Can trace requirements to specific business objectives.
• Can record expected business outcomes in the form of measures or KPIs.
• Focuses on collaboration between stakeholders and developers, placing more emphasis on collaboration and less on rigid requirement documents.
• Allows stakeholders to be engaged throughout the project lifecycle, not just upfront in requirements definition.
• Allows the requirements to be used for benefits realization after the solution has been delivered.