Software architecture

Have you ever had a situation where you worked on something, put your heart into it, and it ended up in the trash? Whether it’s a failed cake or an IT project, it’s painful. In the case of IT projects, one of the biggest pain points is business requirements. Of course, business requirements are good in themselves, so I’ll be more precise:

• lack of requirements

• insufficient requirements

• incorrect requirements

• unclear requirements

All of these things above can cause the project to fail. Ending up in the trash is one of the worst-case scenarios. Failure can also mean higher production costs or longer deadlines.

There is a certain relationship between collecting business requirements and engineering

Engineering is difficult when requirements are not clearly defined. Developers have to think about how something should work instead of focusing on how to solve a specific technical problem. This increases the cost of work and extends the deadline. In this case, gathering requirements was easy because insufficient time was spent on them.

Collecting and documenting specific and clear requirements takes time and people with the right skills. Therefore, this is difficult, but it pays off later - engineering becomes simple. Developers do not have to think about how something should work. They work more efficiently, and the chance that the final project will end up in the trash decreases.

One may wonder what is more profitable: time spent on business analysis or development based on poor requirements. Mature companies that have already messed up X projects know perfectly well what is more profitable.

---

Complete Business Requirements

What does it mean that requirements are good, or as I wrote above: specific?

First, requirements must be clear and understandable for all project participants. They must also be consistent, meaning they can’t conflict with other requirements. A requirement can be considered complete if the client or project sponsor has confirmed it.

---

Project scope vs. product scope

Business requirements must be documented, but it does not mean they must be set in stone and never change. To put it plainly, business requirements can change during work. Nowadays, teams need to be agile and react to these changes. In such teams, there is usually a project manager who is responsible for:

• implementation plans

• monitoring and coordinating work

• reporting to the boss

• replanning

To sum up: the project manager is responsible for this project’s scope, but is he responsible for the scope of the product? What do I mean by the scope of the product? Let me explain:

• business requirements

• acceptance criteria

• requirements management plan

In an ideal world, the business analyst is responsible for the scope of the product, but often one person handles both. Well, everyone accepts their fate and rolls their… ball.

---

Business requirements document

A good practice for documenting business requirements is to prepare a BRD (Business Requirement Document), which translates business goals and needs into business requirements. Such a document often refers to another one called the Product Vision Document (if there is, of course, a product vision;-)). BRD complies with the standards applicable to the organization and the development methodology. This document is the source of truth about business requirements and needs.

Documented requirements describe what a project or functionality should do and are independent of solutions. We come up with a solution later to meet the requirements.

---

Stakeholders

Stakeholder is a word that is difficult to translate into Polish. They are all the people who are involved in the project, and they can be:

• customers

• sponsors

• users

• engineers

Stakeholders are the source of requirements, so the first step in gathering requirements is to list them and determine who they are, what they do, and what their role is in the project.

It is then a good idea to establish what specific responsibilities each stakeholder has and their interest in the project. For example, one stakeholder may want to reduce costs, while another may want to improve product quality and user experience.

It is also crucial to determine how influential stakeholders are and whether they positively or negatively impact the project and others. During the requirements-gathering process, many conflicts may arise that must be resolved.

---

Requirements Gathering Methods

There are many methods for gathering business requirements, and I could probably dedicate a separate article to each of them:

• Workshops

• Brainstorming

• Interviews

• Surveys

• Review of existing documentation

• Review of an existing interface

The last two, reviewing existing documentation and interfaces, involve extracting requirements from something already existing, while the other techniques mainly involve asking questions in different forms. The most interesting questions that can be asked in the requirements-gathering process are:

• What goal is/will be achieved by using the product/process?

• How do you define success?

• How else can this goal be achieved?

• What failures cause the most pain?

• What would it look like if you could use a magic wand and change this process/product?

---

Summary

Acquiring requirements is difficult and time-consuming, but having documented and complete requirements make work easier, especially for distributed teams. Collecting requirements can be easy - if you don’t put effort into it and ignore it. Then, engineering will be difficult and expensive.

There are no shortcuts.

Sources

If you want to read more about collecting business requirements, I recommend the book “Unearthing Business Requirements: Elicitation Tools and Techniques.”