Question

Should Software Engineers question the Honesty of Functional Requirements?

Ethical and Professional Viewpoints

Answer 1

YES Every Software Engineers should question the Honesty of Functional Requirements.

Requirements honesty is the adherence to certain requirements principles. I argue that the quest for faster and faster ways of developing software may impair the satisfaction of these principles. The argument starts with the

consideration of two questions: “why would someone want a functionality in one to three weeks time?” and “why that same person is unwilling to wait two to three months to have the same functionality, if the resulting software is proved to be more appropriate, stable, or easier to maintain?”. Several answers can be given. One could stress the point that is very difficult to assure appropriateness, stability, and other quality factors. If no guarantee can be given that these quality factors are better preserved in a two months development time, then there is no point in taking the longer path to get similar uncertainties. Another answer could note that for some systems the cost of assuring quality factors in a longer time-scale outweighs the benefits. This line of reasoning does not diminish the importance of producing quality products. It just recognises that there are costs involved and difficulties to overcome, and that these should be taken into consideration when deciding the amount of effort devoted to assure quality.
A second line of reasoning takes the market as the driving force. The need to produce in a short time is derived
from the need to be the first in the market. It is a business requirement and a very strong one because it is perceived as related to survivability. I present time-to-market as a mandatory requirement, implying a trade-off between development speed and other quality characteristics that are also important to business survival.

Requirements principles

Purposefulness. There should be an objective to be fulfilled.
Appropriateness. Requirements should be appropriate to
the system. They should express what is necessary to
achieve the system’s objectives.
Truthfulness. Requirements should express what is actually
required.

Purposefulness We build software for some reason. If that reason is fulfilled then the software is successfully built. Of course this idea of success is subjected to ethical considerations. One may, as I do, reject as successful a system built to satisfy unethical or immoral objectives. The point here is that there is always a purpose. Software requirements express part of what is necessary to achieve the system’s objectives by means of software — we may say that software requirements express the software’s contribution to the achievement of these objectives. The determination of the system’s objectives is a difficult task, aggravated in situations in which they are not, or cannot be, clearly stated. Usually there are several objectives satisfying different interests, and determining the right ones is hard. To complicate things a bit more, the system may have unclear or no absolute goals. However, there always will be a negotiated construction of the objectives and the system will always serve some purpose.

Appropriateness Software is just a piece of larger systems; thus, it has to be appropriate to the system in which it is inserted. Determining the software appropriateness amounts to getting the right requirements. In situations in which the objectives are unclear or there are no absolute objectives, the determination of the right requirements is more diffi- cult. In those situations, defining what is needed for a software to contribute to the accomplishment of the objectives comes pari pasu with the determination of the objectives themselves. One of the consequences for the development process is that no user may be regarded as having all the necessary information. Negotiation is usually necessary to define the appropriate requirements and this involves listening to all parties playing a role in the negotiation process.

Truthfulness The assurance that we have the right requirements and subsequently the assurance that we get the requirements right are paramount for the development of software. For complex systems the number of mistakes and errors, and the number of them that may go unnoticed, is large. There are two ways to deal with those mistakes and errors on requirements: one is through requirements analysis and the other is through a process of verification and validation. Requirements analysis try to establish the presence of desirable attributes like consistency, precision, and completeness, among others. Although these desirable properties are no guarantee that the requirements are correct, their presence is a good indication in that direction and the lack of them is a sign that something is wrong or improperly stated.