Definition of software requirement

[Angrry.exe™]

 

The central element in Analysis is certainly the software requirement. Around the requirements is everything: requirements must be collected from customers, requirements must be documented, managed, developed, tested. In fact, the model created by software specifications is a model composed of requirements that have to be transformed into the final product.
For this reason, we will insist on the definitions of software requirements, perhaps even more than the definitions of the Software Analysis itself.

There are a lot of definitions in the literature. However, all attempts to encompass the following essential elements: requirements are descriptions (specifications), in a language accessible to all those involved in what an information system must be able to cover, both by behaviour and by its attributes.

The most complete (and of course the most recognized) definition of the requirement is given by the Institute of Electrical and Electronics Engineers (IEEE). According to this organization, through the IEEE Standard Glossary of Software Engineering Terminology 610.12-1990, the software requirement is defined as follows:

The software requirement is:

1. a condition or capability required by a system to enable a user to solve a particular problem or to reach a particular goal;

2. a condition or capability that a system must achieve or possess in order to meet a contract, standard, specification, or other formally imposed document;

3. a document - the representation of a condition or capability, as described in points 1 and 2 above.

Before looking at this definition, we will clarify the term "capability" used here. Capabilities mean something that a software system provides to users, either a particular behavior or a certain attribute. Although the term comes from English "capability," Romanian has here the privilege of having an intuitive description for capability: it designates something a system is capable of doing, something the system can do.

Through a capability of a system we can designate either behavior or attribute. For example, a "system validates the date format when the user records the system bill" functionality is a system behavior, while the "position of a button on the screen" is an attribute.
(Finally, in Romanian, a field in a database or property of an object may correspond to an attribute of an entity, while a method of an object means behavior.)

Turning to the definition of the requirement, we will briefly detail the three parts of the definition.

The first part represents the point of view of the user. The center of attention is, at this point, the user who needs something to solve a problem or achieve a goal. This part of the definition clearly tells us that if the problem / purpose of the user can not be specified, then the requirement does not exist. A requirement exists as long as it represents the solution for a user problem.

The second part of the definition is the developer's point of view. Here, "a condition or capability that a system has to accomplish" is what the developer must accomplish. As can be seen from the definition, for him the reference is a "formal document imposed". We will see in the following chapters that here is not a description of functions as they develop in programming language but are capabilities that can be understood, have a logic and can be validated by the user of the system without knowing it programming.

The third part of the definition expresses a common viewpoint or a general viewpoint, a basic rule: the first two points of view can not exist unless there is a document that both parties can use as a reference. If the document does not exist, the two points of view and their evolution over time do not have a common, palpable and unambiguous element, an acceptable reference.
Therefore, according to point 3 of the definition of the requirement, a requirement that is not documented does not exist.

We note, from the above definition, that the requirement viewed by the system user is useful for solving a problem, while for the developer the requirement is something he has to develop according to the specification. As a result, the requirement must be expressed in such a way that it can be interpreted without doubt on both sides, because it is equally intended for both sides.
On the one hand, it is important for the user to solve their own problems, without the technical details of solving them being relevant. On the other hand, the developer needs a reference to know what to develop, while user issues are less relevant. Here, in the middle between the two is the Software Analyst and its work product: the software requirement - a document that looks useful