Although often confused, requirements engineering and business analysis are decidedly not the same. Understanding the differences is key for successful IT projects. Requirements engineering, although helpful, is certainly not the key for success on business IT projects. Let’s explore the differences.
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.
- Typically deals with large complex systems in which software is only a component, (e.g., airplanes, naval vessels, hydroelectric plants, etc.).
- Two primary activities:
- Requirements development.
- Requirements management.
- Requirements are related to products, not processes.
- Requirements engineering addresses only functional and nonfunctional 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 BA 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.
- Typically used in enterprise projects where people, process, and technology issues must be addressed.
- Four primary requirement activities:
- Elicitation.
- Requirements development.
- Requirements management.
- Requirements communication.
- Many additional other non-requirement activities.
- Solutions are focused on using technology to help people performing business processes.
- Solutions are often purchased instead of built (ERP Systems).
- Addressing organizational change and business process change is critical for success.
- Business analysis involves facilitating business change.
- Delivering business value and ROI are expected.
- There are five types of requirements: business, stakeholder, functional, nonfunctional, and transition.
Selecting a Requirements Management 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 only allowed for defining functional and nonfunctional requirements and did 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 Requirement 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 Business Analysis Body of Knowledge
- Business Analysis Planning and Monitoring:
- Elicitation
- Requirements Analysis
- Requirements Management and Communication
- Enterprise Analysis
- Solution Assessment and Validation
- Captures all five types of requirements as defined by the IIBA (Business, Stakeholder, Functional, Nonfunctional, and Transition).
- Focuses more on customer collaboration over rigid engineering specifications.
- Addresses people, processes, and technology, not just technical specifications.
- Can trace requirements to needed business processes changes.
- Provides a stakeholder impact assessment capability within the tool.
- Can link requirements to IT services and components.
- Captures stakeholder needs separate from requirements with full traceability from requirements to stakeholder needs.
- Can define the problem statement within the tool.
- 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.
- Can define the business case within the tool.
- Allows the requirements to be used for benefits realization after the solution has been delivered.
- Can be used various types of projects, not just defining requirements for a product:
- Organizational transformation
- Business Intelligence
- Packaged Software Evaluation and Selection
- ERP System Upgrades
- Data Warehousing
- Business Process Improvements
- Mergers and acquisitions
- Customer Facing Web Applications
- Systems Maintenance
[cta id=”7436″]