SQA — Defining Requirements

Defining software requirements is now considered a speciality, which means a business analyst or a software engineer specialized in requirements. Requirements definition is the topic of interest groups as well as the subject of professional certification programs (see http://www.iiba.org).

There are a certain number of problems related to the clear, correct, and concise writing of requirements so that they can be converted into specifications that can be directly used by colleagues, such as architects, designers, programmers, and testers.

It must also be understood that there are a certain number of activities that must be mastered when eliciting requirements:

— identifying the stakeholders (i.e., key players) who must participate in the requirements elicitation;

— managing meetings;

— interview techniques that can identify differences between wishes, expectations, and actual needs;

Figure 1.1 Context of software requirements elicitation.

– clear and concise documentation of functional requirements, performance requirements, obligations, and properties of future systems;

— applying systematic techniques for requirement elicitation;

— managing priorities and changes (e.g., changes to requirements).

It is clear that errors can arise when eliciting requirements. It can be difficult to cater to the wishes, expectations, and needs of many different user groups at the same time (see Figure 1.1). Therefore, it is important to pay particular attention to erroneous requirement definitions, the lack of definitions for critical obligations and software characteristics, the addition of unnecessary requirements (e.g., those not requested by the customer), the lack of attention to business priorities, and fuzzy requirements descriptions.

A requirement is said to be of good quality when it meets the following characteristics:

— correct;

— complete;

— clear for each stakeholder group (e.g., the client, the system architect, testers, and those who will maintain the system);

— unambiguous, that is, same interpretation of the requirement from all stakeholders;

— concise (simple, precise);

— consistent;

— feasible (realistic, possible);

— necessary (responds to a client’s need);

— independent of the design;

— independent of the implementation technique;

— verifiable and testable;

— can be traced back to a business need;

— unique.

We will present techniques to help detect defects in requirements documentation in a later chapter concerning reviews.

We must also ensure that we are not looking for the Holy Grail of the perfect specification, since we do not always have the time or means, or the budget, to achieve this level of perfection.

The article by Ambler [AMB 04] entitled “Examining the Big Requirements Up Front Approach” suggests that it is sometimes ineffective to write detailed requirements early in the life cycle of a software project. He claims that this traditional approach increases the risk of a project’s failure. He stipulates that a large percentage of these specifications are not integrated into the final version of the software and that the corresponding documentation is rarely updated during the project. He thus asserts that this way of working is outdated. In his article, he recommends using more recent agile techniques, such as Test-Driven Development, in order to produce a minimum amount of paper documentation.

We have observed that software analysts and designers also often use prototyping, which helps to partially eliminate the traditional requirements document and replace it with a set of user interfaces and test cases that describe the requirements, architecture, and software design to be developed. Prototypes prove useful for pinpointing what the client is envisioning and getting valuable feedback early in the project. In the next section, the development practices adopted by different business sectors will be discussed.

1. Maintaining Effective Communications Between Client and Developer

Errors can also occur in intermediary products due to involuntary misunderstandings between software personnel and clients and users from the outset of the software project. Software developers and software engineers must use simple, non-technical language and try to take into account the user’s reality. They must be aware of all signs of lack of communication, on both sides. Examples of these situations are:

— poor understanding of the client’s instructions;

— the client wants immediate results;

— the client or the user does not take the time to read the documentation sent to him;

— poor understanding of the changes requested from the developers during design;

— the analyst stops accepting changes during the requirements definition and design phase, given that for certain projects 25% of specifications will have changed before the end of the project. To minimize errors:

— take notes at each meeting and distribute the minutes to the entire project team;

— review the documents produced;

– be consistent with your use of terms and develop a glossary of terms to be shared with all stakeholders;

— inform clients of the cost of changing specifications;

— choose a development approach that allows you to accept changes along the way;

— number each requirement and implement a change management process