Skip to main content

Requirements Engineering

Introduction​

Inventory Icon

Requirements engineering is the process of identifying and describing what the system should actually do and what constraints the system needs to meet. In waterfall processes this is a long and complex process done at the beginning of the project prior to starting development. Usually this will involve numerous reviews and revisions before a complete requirements document is accepted and development can begin.

While Agile methodologies typically encourages us to forsake this sort of complex documentation it is still common to start a new project by determining some basic requirements and limitations. We really want some confidence that we’re building something that people actually want, and the requirements engineering process can really help with that.

Requirements fall into one of two categories

  • Functional requirements: What does the system need to do. What value does it provide to the user.
  • Non-functional requirements: What constraints or limitations is the system subject to.

While these types of requirements may appear to be distinct, there is often overlap between the two. For example: a non-functional requirement related to system security requires including functional requirements to support user creation and authentication.

Stakeholder

When discussing requirements, you should always do so from the perspective of some stakeholder. A Stakeholder is anyone who has a vested interest in the system being developed. This could be the end user, the customer, the developer, the project manager, or any other person who has a vested interest in the system being developed.

Not all stakeholders will have the same objectives, and it is important to think about requirements with specific stakeholders in mind.

What is a Requirement?​

Like many terms in software engineering, Requirement is not used consistently in the industry, or even within a single project's lifecycle. It could mean, a high-level abstract description of a service, or it could mean a detailed, formal definition of a system function.

Consider a set of requirements created in order for a company to outsource the creation of some large software development project. The requirements needs to be written in a sufficiently abstract way that a solution is not predefined. Several contractors might bid for the contract, offering different ways to fulfill the requirements.

Once a contractor has been awarded the contract, they will need to create a detail system description for the client in order for the software to be validated.

In both cases, the document is called a requirement, but the level of detail and the purpose of the document are very different. This lack of clear definition complicates the already difficult requirement engineering process.

For our purposes, we will define a requirement as a statement that describes a system feature or constraint. This could be a high-level abstract description of a service, or a detailed, formal definition of a system function depending on what is needed.

Mechanical Icon

Requirements Engineering Process​

The requirements engineering process is typically broken down into three phases:

  • Requirements Elicitation: This is the process of gathering requirements from stakeholders. This can be done through interviews, surveys, or other methods.
  • Requirements Specification: This is the process of documenting the requirements in a way that is understandable to all stakeholders. This is typically done in a requirements document.
  • Requirements Validation: This is the process of ensuring that the requirements are correct and complete. This is typically done through reviews and testing.

It is easy to think about the requirements Engineering process as a simple linear sequence of steps, but this is overly simplistic. In practice, this process is always iterative in which the activities are interleaved throughout. These steps are almost always taken in some sort of cycle, with one defined requirement leading to the need for some additional related requirements.

Requirements Spiral
  1. We might start with a rough idea of a system we want to build (Elicitation)
  2. Then we document the business needs (Specification)
  3. Followed by a feasibility study to determine if we can afford to build it and if anyone would want it (Validation)
  4. Then we start gathering more detailed user requirements (Elicitation)
  5. Creating a requirements document would be next (Specification)
  6. Then we might build a prototype, which is another kind of validation
  7. Then we might want to identify more detailed system requirements based on performance problems with the prototype (Elicitation)
  8. Then we would document those system requirements for the Architects to use in the system design (Specification)
  9. User feedback and reviews after release would be Validation once again

I'm presenting the requirements process as a linear sequence, but that is just to simplify the explanation. The real process is never as clean cut as that.

Onboarding Icon

Requirements Elicitation​

The goal of the requirements elicitation process is to understand the needs of the stakeholders, and the services that a system would need to provide in order to support those needs. We also need to understand the constraints that the system would need to operate under.

The ideal outcome from this process would be a complete and consistent list of everything that the system will be able to do once complete, as well as a complete list of any limitation the system is subject to. This is an impossible task and simply never happens. The more realistic outcome of this process is a list of next features to be worked on and any limitations that we know of. Keeping the focus on the short term helps us create a more realistic plan.

Most teams will probably have a reasonable idea of what the system will do by the end of the quarter. High functioning teams might even be accurate 2-3 quarters out. Longer than that is little more than a guess and should be treated as such.

Regardless of whether you are building a system for internal use, building a product to sell, preparing to outsource to contractors, or to fulfill a contract, this process is extremely difficult to do well.

Why is Identifying Requirements so Difficult?​

Correctly identifying requirements is extremely difficult to do with any degree of accuracy. Some reasons that this is so hard:

  • Stakeholders often don't know what they want from a computer system except in the most general terms.
  • Stakeholders may make unrealistic demands because they don't understand what is feasible.
  • Stakeholders tend to express requirements in their own terms, with implicit information that may not be obvious to an outsider.
  • Different stakeholders may express requirements is contradictory ways.
  • Economic and business needs are constantly changing.
  • Political and bureaucratic factors may influence the system requirements.

Requirements Elicitation Process​

We can break requirements elicitation into 4 main steps:

  1. Discovery and understanding: What are the requirements? What are the limitations?
  2. Classification and Organization: Once some requirements are identified we need to break them into groups. This allows us to eliminate duplicates and identify contradictory requirements.
  3. Prioritization and negotiation: Which requirements are the most important? Separate the "must have" from the "nice to have".
  4. Documentation: Initially this is less formal than the specification process, but the act of documenting the requirements will often lead to new rounds of discovery.

Techniques for Requirements Elicitation​

There are many techniques for requirements elicitation. Some of the most common include:

  • Interviews: One-on-one discussions with stakeholders. This usually starts with a prepared list of questions, and then spreads out into a more free-form discussion.
  • Questionnaires: A set of written questions that stakeholders can respond to.
  • Observation: Watching stakeholders work to identify requirements.
  • Workshops: A group of stakeholders work together to identify requirements.
  • Prototyping: Building a simple version of the system to help identify requirements.
  • Use Cases: A description of how a system will be used.
  • User Stories: A description of a system feature from the perspective of the user.

Of these, the most common are interviews and observation, but to get a complete picture of the requirements you will likely need to use multiple techniques. Each of these will leave gaps that can be filled by the others.

Requirements Specification​

Once requirements have been identified we need to document them so they can be clearly communicated. This is typically done in a requirements document. This document will be used by all stakeholders to ensure that everyone is on the same page.

An ideal requirements document should be unambiguous, easy to understand, complete, and consistent. In practice, achieving all of these is impossible. Readers of the document will always have their own interpretation, and there are often inherent conflicts in the requirements.

Most requirements documents end up being a combination of different formats brought together into a single description. They may include some or all of the following:

  • Natural language sentences that express the requirements in a way easily understandable by the users
  • Structured natural language in which the requirements are built on a standard form or template
  • Graphical models are diagrams describing the functional requirements for the system
  • Mathematical specifications are usually based on things like state machines or sets. These have the advantage of being unambiguous, but usually cannot be understood by stakeholders

In most cases, these documents go through different formats over the lifetime of the requirement. They usually start as simple natural language sentences, often on sticky notes or the digital equivalent. After some initial sorting and organizing, they are added to some sort of ticketing system with a clear template. Later, diagrams might be added. Finally, the requirements are added to a formal document that is used for validation.

Quality Control Icon

Requirements Validation​

The cost of fixing a requirements problem after implementation is usually much higher than the cost of repairing a design problem or coding error. A significant misunderstanding in the requirements typically results in a major redesign, new implementation work, and a retest of the system.

Some common validation checks include:

  • Validity checks ensure that the requirements reflect the actual needs of the customer
  • Consistency checks ensure that the requirements are compatible with each other
  • Completeness checks look for missing requirements, functionality, or system constraints
  • Realism checks ensure that the requirements can actually be implemented within a budget
  • Verifiability aims to reduce potential disputes between the development team and the stakeholders

Requirements validation techniques​

  • Requirements Reviews: A team of reviewers systematically check the requirements looking for errors and inconsistencies
  • Prototyping: Develop an executable model of the system that can be demoed to the stakeholders to ensure it meets their needs and elicit feedback
  • Test Case Generation: Write test cases for the requirements. If a test is difficult, or impossible, to design, it implies that the requirement will be difficult to implement.

Conclusion​

The Requirements Engineering process is about identifying the describing the system. It allows us to understand the needs of the stakeholders, and how the system will meet those needs.

It is not a simple linear process, but rather an iterative process that is constantly evolving. You should be constantly checking on current requirements and looking for new ones.

This process is extremely difficult to do well, but it is essential to the success of any software project.

Image Credits​