Business analysis is a set of activities and techniques used to work as a liaison between stakeholders to understand the structure, policies and operations of an organization and to recommend solutions that will help the organization achieve its goals. That being said, the best way to describe the role of a business analyst is to imagine the bridge between business stakeholders and developers. On that bridge, a business analyst is translating the business requests and needs into more technical language which is more friendly to developers representing the technical side.
But what if the project doesn’t have the luxury of adding a business analyst as part of the team? Then the requirements’ part may fall directly between business stakeholders and developers. It adds an addAnalitional challenge for every project since neither side may have the skills or tools to manage that aspect of the project at the highest level.
This article hopefully will help you to avoid such situations. It is dedicated to developers and engineers who are responsible for turning stakeholders’ ideas into reality without the support of business analysts. Having a deep understanding of the role of requirements in a system’s development life cycle will help you succeed.
In this article, we will focus on answering the following questions:
- What are requirements?
- What role do requirements play in a system’s development life cycle?
- How to work with requirements?
- How can I work with requirements?
What are the requirements?
Every systems development project needs a driving force. Rapidly changing technologies and increasing competition put constant pressure on the development process. Effective requirements engineering is at the heart of an organization’s ability to lead and to keep pace with the rising tide of complexity.
There is a constant pressure to improve products and services, and software is the dominant force of that change. There are several reasons for this:
- The most complex systems tend to be those with software, often integrated deep inside the system’s components.
- Today a company can come up with a new product, implement it in software, and instantly distribute it around the world. Mobile apps are a perfect example of this.
- Systems are now build from bought-in technology and ready-made components which significantly reduces the cost and time of the product development cycle.
Such trends intensify competition and the ability to maximize profits from the new technology without spending money on additional facilities or equipment. As a result, there is pressure to shorten the development cycle and the time needed to deploy new technology. The main goal in a fast-changing environment is to reach the market on time with the “right product”. Establishing the requirements enables us to decide and visualize the “right product”.
Requirements are at the center of every project, defining what the stakeholders (users, customers, suppliers, developers, businesses) need from a new system and what it must do to satisfy that need.
Types of requirements
There are two types of requirements:
- Functional requirements – describe what the system should do. These are the processes, information and interactions that the client wants to build and include how the system and its environment interact.
- Non-functional requirements – are not directly about the functions of the system. They are properties of the system and often its limitations. These requirements are about operational and technical aspects, like encryption, security, disaster recovery, hosting and business continuity.
Requirements are usually expressed in natural language to be well understood by all involved parties. But it also creates a challenge: how do you capture a need or problem to avoid ambiguity or vagueness without using specialized jargon or conventions?
Agreeing on requirements drives project activities. Agreed requirements provide the basis for planning the development of a system and accepting it on completion. Requirements are a complete snapshot of what we expect at each level in increasing detail.
What role requirements play in the system’s development life cycle?
Requirements form the basis for:
- Project planning,
- Risk management,
- Acceptance testing,
- Change control,
- Quality.
Project Planning
Requirements play an important role at each stage of development. The following model shows the various stages of development and the relationship between testing and requirements. The V-model also considers the development part as a set of layers, where each layer covers the corresponding development stage.
Risk management
Even if the problem to be solved and potential solutions are defined we need to assess the risks of not having a satisfactory solution. Requirements enable risk management from the earliest possible point in the development life cycle. Concerns or dependencies associated with requirements can be tracked, their impact assessed, and mitigation and backup plans carried out long before significant development costs emerge.
Acceptance testing
Requirements drive the testing strategy at every level of the project. The main purpose of testing is to detect whether the system is working as expected. This makes it possible to prevent any defects in the system and indicates where there is a requirement derivation. Testing activities include reviews, inspections and analysis through modeling, but also classic testing components, subsystems and impacted systems.
Requirements not only provide a good basis for development. It is also important to view requirements as the basis for the final review or validation when the system (or component) has been implemented. This is achieved by applying certain criteria to each requirement, which will then be used to determine whether the system meets the customer’s actual needs.
Change control
Because requirements play a key role in systems development, they must be maintained at every stage of the project. Changing the design of a product without updating the requirements to reflect that change can lead to an accumulation of challenges at later stages of development. This demonstrates how requirements are closely linked to change management.
Whether modification comes from within a project (for example, technical issues arising in the design details) or from outside (such as changing stakeholder needs), the impact of the change on quality, cost and schedule needs to be estimated. That assessment can create one of the following scenarios:
- Accepting or rejecting the change (where that is a choice),
- Negotiating the cost of the change with the customer/suppliers,
- Organizing the work associated with the change.
Quality
Many systems have failed because the requirements were not properly defined or organized. The result of such a situation can be a system which initially appears to work, but if it is not the system that users want or need, it will be useless.
This brings us to the relationship between requirements and quality. In this case, the term quality refers to how well the system is fit for purpose or how well it conforms to requirements. It refers to how well the system ensures that customers’ needs are met.
How to work with requirements?
Engineer requirements process
The figure below illustrates the process of establishing requirements. It starts with the need to agree with the stakeholders on the high-level input requirements for the project. That creates the baseline for analyzing the input information and exploring how this can be achieved. The result of the second phase is the creation of derived requirements.
During the analysis of input information, agreements are made with stakeholder as to which requests will be included. This stage also involves the creation of models and leads to analysis reports, which together form the basis for deriving requirements and qualification strategy. The outcome of that analysis process can be a set of derived requirements. Each set must be agreed with the relevant supplier.
The cap example
Proper understanding of a system’s requirements requires an understanding of the enclosing system. Often, the correct functioning of a system depends on the provisions of the surrounding system.
Let’s break down the following example: the cap. It is made of several components: a handle and a bowl-shaped container. What is the purpose of each component? The bowl is used to store liquid, and the handle allows you to hold the bowl without getting burned.
Therefore, the requirement is that the cup should enable a person to transfer hot liquid to his mouth without spilling or burning it.
The cup has many features and functionalities. It can be placed on a flat surface for stability; it can be held in a human hand; it can be filled with substances of different states; it must interface with the fluid for sustained containment; and it must deliver fluid to the human mouth.
However, other observations should be made:
- The cup is no good by itself. Its operation depends on the movement of the human arm.
- The cup’s bowl part depends crucially on the presence of gravity for its proper functioning. It must also be used correctly: holding the cup upside down will cause spills and can cause burns.
Summary
This example shows that the engineering of requirements must take into account the nature of systems. The usability of a system does not depend on any particular part of the system, but is a result of the way its components interact with each other.
To be continued… (in the next article: Tips and tricks for effective requirements gathering)
Sources
- Elizabeth Hull, Ken Jackson and Jeremy Dick, Requirements Engineering, Springer London Berlin Heidelberg, 2005
- Business Analysis Book of Knowledge (BABOK v3)
- The BA Skill Set – 5 Whys Technique
- 10 steps to successful requirements gathering
- What you need to know about requirements gathering
- 5 best practices for an effective requirements gathering process
- 12 techniques for requirement gathering
- A 6-step guide to requirements gathering for project success
***
If you are interested in the topic of requirements, also take a look at other articles by our experts (in Polish and English).
Leave a comment