Types of requirements. Examples

Requirements types

Continuation of the Requirements types overview. The previous post see here.

“Transitional requirements” is the group of requirements, which operates while the solution is being formed. Transitional requirements are formulated while searching for solutions to the business problem. At this stage, the analysis of business processes is carried out pretty often, which brings us to diagrams forming process using various methodologies and tools (BPMN, ARIS, etc.). Once the decision is made, transitional requirements cease to exist or become components of decisions.

For example, transitional requirements:

  • It is necessary to analyze the possibility of entering the foreign market;
  • it is necessary to analyze business processes, identify the prerequisites for re-engineering and automation.

As a result, the transitional requirement can become a decision component. The decision, obviously, can include several components.

There can be two types of requirements for the decision components: those which can be automated and those which can not.

For example, the requirements to the components of the following aim “to enter a foreign market of neighboring countries” (for the publishing house in Luxembourg):

  • it is necessary to consider the markets of Dutch and French speaking countries (The Netherlands, Belgium);
  • or it is necessary to publish books in the language of the country where the market is planned to be released (German language for Germany, etc.).

The requirements here are obviously can not be automated.

On the other hand, the requirements for the decision component “to implement the CRM-system” will be formulated in the form of user stories or functional specifications. These requirements can be automated. Right after the concept is formed, the next step is their establishment.

Here are some examples of different requirements types which can be automated:

  • user requirement (in the form of user stories): as a client, I can enter the data required for registration in order to register within the system and get access to the extended catalog of goods;
  • functional requirement: the system should be able to register clients (pretty often can be accompanied by functional prototypes establishment);
  • requirements to data (database): while registering, the client must specify the name, e-mail and password;
  • nonfunctional requirement (performance): the registration form shouldn’t be loaded for more than 1 second.

Author: Veronika Baeva, see original resource in Russian.

Leave a Reply

Your email address will not be published.