Navigating the Challenges of Requirements Engineering

Introduction

After analysing the business environment of Unhappy Bank and it’s current state, deciding how to measure success of the digital transformation project, evaluating the business changes required, the risks they might have and bringing together the different stakeholders, it was about time to gather all the requirements, or all the features that the stakeholders wanted to have to reach the “to-be” stage.

To avoid the risk of delivering functionality that fails to meet the requirements, it was imperative to establish practices and processes for creating well-formed business requirements.

Hierarchy of Requirements

Stakeholders can have any requirements they believe are important. It is up to the business analyst to categorise them. There are two ways to do that:

  1. General and technical: For example a general requirement was to provide customers with an efficient and user-friendly banking app that allowed them to access their accounts and conduct transactions securely from anywhere, at any time. A technical requirement was to ensure that the online banking platform was built using secure and up-to-date technology, such as SSL encryption and two-factor authentication, to protect customer data and prevent unauthorised access.
  2. Functional and non-functional: An example of a functional requirement was that the ATM machines must allow customers to withdraw cash using their debit cards while a non-functional requirement was that the ATM machines must have a response time of less than 5 seconds for every transaction.

Types of Requirements

There are different types of requirements that need to be considered when designing and implementing a solution.

Business requirements describe the high-level objectives and goals of the organization, such as defining policies, standards, and needs, as well as any constraints that must be adhered to, including legal, branding, cultural, and language requirements.

Technical requirements, on the other hand, specify the hardware, software, and technical policies and constraints that must be met. For example, interoperability standards may need to be established to ensure that different systems can communicate and exchange data effectively, especially for solutions that operate on the internet.

The solution requirements define the functional and non-functional aspects of the solution. Functional requirements describe the features of the solution, such as data entry, data maintenance, procedural and retrieval processes. Non-functional requirements, unfortunately often missed out, describe how well the solution will operate in terms of performance, security, archiving and retention, and maintainability.

By identifying and prioritizing each type of requirement, organizations can design and implement solutions that meet the needs of their stakeholders and align with their business objectives. Effective management of these requirements throughout the project life cycle is crucial for delivering high-quality solutions that meet the expectations of all parties involved.

Requirements Engineering Approach

The below diagram indicates the different stages of a requirements engineering approach. Each stage is described in details in the following sections.

Requirements Elicitation

Requirements elicitation is the process of identifying, gathering, and documenting the needs and expectations of stakeholders for a particular system or product. The main objective of requirements elicitation is to ensure that the system or product being developed meets the needs of its intended users and stakeholders. The requirements elicitation process is typically conducted in the early stages of a project, and the results are used to guide the development of the system or product and to manage stakeholder expectations throughout the project lifecycle. The business analyst team decided that all requirements should be documented, even those that were dropped early in the project.

It’s important to note that there are two types of knowledge:

  • Tacit: Aspects of business that a user is unable, or omits, to explain.
  • Non-tacit/Explicit: Procedures and data that the business users can explain.

Different investigation techniques were used to elicit requirements from Unhappy’s Bank stakeholders.

Requirements Analysis

Requirements analysis involves identifying and defining the needs and constraints of a system. This process helps to ensure that the final product meets the expectations of stakeholders and users by identifying, documenting, and validating their requirements. The goal of requirements analysis is to ensure that the development team has a clear understanding of what they need to build, and that the end result meets the needs of all stakeholders.

This is the stage where all requirements identified during requirements elicitation will be developed into clear, organised and well-documented requirements.

The below diagram illustrates the different tasks that are needed for this stage and examples of the digital transformation project of Unhappy Bank.

After analysis, each requirement should have the following quality characteristics:

  • Testable: A requirement has to be described in a way it can be tested. Requirements should always be used as the input for testing scenarios.
  • Unambiguous: Correct terminology. All the people that read the requirement should have the same understanding.
  • Relevant: Within the scope of the project.
  • Clear: Clear language without any “and”, “but”, “until”
  • Complete: Something that is actually required
  • Consistent: Must not contradict other requirements.
  • Traceable: Full traceability such as source.

Requirements Validation

Once the requirements have been elicited and analysed, it is important to verify that they fully encompass the needs of the stakeholders. The method of validation will vary depending on the lifecycle being utilised, but the fundamental objective is to confirm that the complete solution has been delivered by fulfilling the stated requirements.

If possible, all related stakeholders should review and sign off the requirements document.

  • Business sponsor: To ensure that requirements are according to the business objectives
  • Business owners: To ensure that requirements express the business needs
  • SME: To ensure that requirements reflect correct business practice.
  • Developers: To ensure that requirements are technically feasible.
  • Testers: To ensure that requirements are testable
  • Project office representatives: To ensure that requirements are compliant with business standards and policies

The possible outcomes of asking feedback from the above stakeholders can be one of the following:

  • Baselined: Official sign off
  • Amendments: Minor changes to clarify requirements.
  • Rework: Requirement is not clear and needs to be analysed again.