What is a requirement?

We can’t start analyzing any requirement in software engineering without a proper definition. According to Mastering Business Analysis Standard Practices by Kelley Bruns and Billie Johnson:

“It’s a condition or capability that is necessary and is a usable representation. A requirement represents what is needed for a product, service, or result”.

The second part of this definition is very important because it mentions NEEDS. In software development business needs are represented by requirements (multiple requirements can meet one business need!). I’ve recently written a piece about business needs and user stories in software development, so give it a read if you’re interested.

Types of software requirements

Requirements can be divided into several types:

• business requirements – critical for the organization as a whole, include software requirement document with needs and expectations for a future product,
• stakeholder requirements – describe what users can do with the product (use cases, scenarios, user stories),
• solution requirements – sums up business and user requirements to describe problems that the product must effectively solve.

There is also a division into:

• functional requirements – basic product behaviour and responses to inputs (what it does and mustn’t do),
• non-functional requirements – performance of a system as a whole, rather than specific behaviours (that includes security, scalability, usability, etc.).

All the aforementioned requirement types should be taken into account during the software project duration and written down in the software requirements document so as not to omit anything.

There are several methods for describing requirements and creating software requirement documents. The most popular ones are definitely User Stories and Use Cases. Regardless of what form of requirements document you choose, you can start testing them from the moment the requirements specifications are created.

Why should you do this at such an early stage? A good argument for testing at such an early stage, that I wholeheartedly agree with, is presented here:

“Many bugs emerge in software because of incompleteness, inaccuracy and ambiguities in functional requirements”.

It shouldn’t come out as a surprise. After all, before you start to develop any software you need to make sure that everybody in the development team is on the same page and clearly understands the project’s logic.

How to write a good description?

What should you pay attention to in order to deliver a high-quality requirement? The table below presents a software requirement specification template prepared by gitconnected. By following these recommendations, you can create good software requirements that are independent of each other and at the same time meet business needs.

A very similar approach to the one presented in the table above can be found in the INVEST method. From this abbreviation, you get the following values:

• Independent – there are no elements making the completion of our task dependent on other teams,
• Negotiable – until the work begins, you can work on the content and scope of the task,
• Valuable – provides new value, primarily for the user,
• Estimable – everything must be valued, otherwise, it won’t be tasked,
• Small – possible to plan and task,
• Testable – the task is only finished when the team is able to successfully test it.

A good rule that I personally try to follow when describing requirements (in particular at the stage of creating acceptance criteria) is to consider dividing tasks into smaller ones when the number of acceptance criteria begins to exceed four points. Of course, this is not a rule of thumb, but it works in most cases.

You should also remember that the task description must be adapted to your readers. Some people like very detailed descriptions, while others prefer high-level descriptions so that they have freedom of action. Nevertheless, regardless of the task description, its quality should be thoroughly checked.

An error becomes an error when it is born as truth

Everyone who deals with maintaining quality and software testing knows that an error detected early causes lower fixing costs. Therefore, you should maintain high quality from the very beginning of the project while preparing the software requirement documentation. Luckily, there are several methods to check whether the written requirements and software specifications meet your quality criteria.

The first step you can take is to validate the requirements. It’s a very important element of the requirements gathering process. It involves evaluating the business analysis information to ensure that it accurately reflects the stakeholder’s intent. In other words, you present what you heard and ask if you understood your stakeholders correctly. Remember that even the best stakeholders may omit some significant elements with an impact on the final implementation, so stay vigilant.

To avoid this situation, follow the entire process-to-be with the requirements you’ve created. To conduct this type of requirement analysis, it is worth writing test cases at the stage of creating your requirement description.

I personally use the Gherkin language for this purpose which, using a descriptive language, guides you through all the steps that your user or the system itself will perform in the future.

It is a very simple form that often allows me to find some inaccuracies or missing information that needed to be completed. Gherkin comes from the so-called “Behavior-Driven Development” and includes some fixed elements:

• Feature – description of the functionality that you will implement or test,
• Scenario – description of what the given case will check, what path you want to go,
• Given – description of the initial condition that must be met in order to perform a test case,
• When – description of the action that triggers the reaction of your system,
• Then – description of our system’s reaction to the previously triggered action,
• And – description of elements that must be met in the initial conditions or the reaction that will follow the action.

How to create your own software requirements specifications?

As I mentioned earlier, QA specialists should be included from the very beginning of the project and also be involved in creating the project documentation to ensure the highest quality of the delivered product. Spotting inaccuracies or gaps at the early stage of creating requirements will significantly reduce the cost of fixing the system in its later stages of development.

Nevertheless, not only the QA team but also all stakeholders involved in the process should be responsible for the final quality of the delivered product. Everyone who participates in creating and analyzing requirements should ask themselves some questions, presented by Karolina Zmitrowicz and Radosław Smilgin:

• Are all the requirements correct?
• Are all the requirements feasible?
• Are all the requirements measurable?
• Are all the requirements testable?
• Are all the requirements single?
• Are all the requirements understandable?
• Do all the requirements have a priority?
• Are all the requirements unambiguous?

If you answer YES to all those questions, then you can conduct a validation with stakeholders whether their need is understood well, and then proceed to implementation.

By taking proper care of creating good requirements in software engineering, you will have greater certainty that the delivered solution is honestly well done and will meet the expectations of your end-users and stakeholders. But what is equally important, it will reduce the risk of complications or other negative effects of a wrongly written requirement of software specification.