29.06.2023

Functional specification and requirement specification – What is it actually?

A basic problem, especially in IT projects, is usually the verbal formulation of the requirements for the result. The solution is a specification - right?

Wann ist Lastenheft & Pflichtenheft sinnvoll?

Fraternal Twins: Functional and Requirement Specifications

Functional specification and requirement specification - What is it actually?

Inhaltsverzeichnis

A basic problem, especially in IT projects, is usually the verbal formulation of the requirements for the result.

Usually, the client and the contractor meet through a standard means of communication. In most cases, the client formulates his wishes for the project (e.g. implementation of a JTL shop template) and the contractor formulates his effort (e.g. offer).

Collecting the requirements is usually not an easy task for shopkeepers. He can be supported in this step by a briefing and consultations. In practice, the boundary between the requirement specifications and the functional specification is usually to be seen as a smooth transition between the two documents.

It’s as simple as that – and yet so hard.

This is because the stumbling block lies in the formulation of the requirements. Here, there can be a big difference between the verbally or even written wishes and the services understood from them.

Example: Ordering a new car

A good example – Buying a new car:

At the car dealer, the customer formulates his wishes for the car, lists his extras and the car dealer interprets the desire for a station wagon from all wishes.
He had the car built and delivered the station wagon.
However, the customer would have thought of a limousine and is of the opinion that he also formulated it that way

A nice picture of the misunderstanding in communication – both sides were sure to have understood everything correctly.

Buying a car

How can such a case be prevented?

It’s important to ask the right questions and put the results in writing. From the contractor’s point of view, structure and recurring processes are very important, because the client usually has less experience with IT projects.

This is the view of the contractor, how did he understand the requirements of the specifications? It contains the concrete paths that should lead to the goal, i.e. concrete implementation components.

How and with what are the objectives of the specifications to be achieved?

A good specification includes the following descriptions: Goals and also the Non-goals. So what should the template “be able to do” and what should it “not be able to do”(e.g. navigation should extend from top to bottom – it should not be fixed at the top when scrolling with the mouse).

In this way, a good distinction can be achieved between desired and undesirable services. This helps very well in estimating the effort and also in the subsequent implementation and approval by the client.

Later touch-ups and corrections can ideally be avoided for the most part, and thus effort and money.

It is the client’s point of view and contains the written requirements for the project. This is already the first positive effect, the creator is forced to deal with his wishes in more detail and to formulate them in such a way that a third party can understand them.

The language should be chosen from the user’s point of view (here: shop operator), simply and without prior specialist knowledge.

A recommended structure would be:

Current status: What should the overall project be based on and what prerequisites are already in place?
Desired target state: thus describes the objectives of the overall project. What should the product contain after completion?
Definition of responsibilities and interfaces: Who is responsible for which areas in the project and where do these responsibilities meet?
Functional requirements: What do you want the product to be able to do functionally (such as user login)?
Non-functional requirements: for example, reliability, maintainability, usability, and so on.

When does it make sense to have a requirement specification and functional specification?

In principle, always, but this is always a question of effort. The specifications are part of the service and must be paid for by the client. As a result, for budget reasons, a specification should only be commissioned from a certain project size.

However, the specifications can actually always be formulated. A concise specification sheet is also better than a simple list of requirements. In particular, the effect that the client has to deal a little more deeply with his project has an effect.

In addition, after the formulation, you have a good and uniform document at hand for obtaining various offers.