1.3.1 Problems with Defining Requirements

Defining software requirements is now considered a specialty, 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;
• – 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.4). 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 in 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.3.2 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 (as it will be presented in another chapter).

1.3.3 Deviations from Specifications

This situation occurs when the developer incorrectly interprets a requirement and develops the software based on his own understanding. This situation creates errors that unfortunately may only be caught later in the development cycle or during the use of the software.

Other types of deviations are:

• – reusing existing code without making adequate adjustments to meet new requirements;
• – deciding to drop part of the requirements due to budget or time pressures;
• – initiatives and improvements introduced by developers without verifying with clients.

1.3.4 Architecture and Design Errors

Errors can be inserted in the software when designers (system and data architects) translate user requirements into technical specifications. The typical design errors are:

• – an incomplete overview of the software to be developed;
• – unclear role for each software architecture component (responsibility, communication);
• – unspecified primary data and data processing classes;
• – a design that does not use the correct algorithms to meet requirements;
• – incorrect business or technical process sequence;
• – poor design of business or process rule criteria;
• – a design that does not trace back to requirements;
• – omission of transaction statuses that correctly represent the client's process;
• – failure to process errors and illegal operations, which enables the software to process cases that would not exist in the client's sector of business—up to 80% of program code is estimated to process exceptions or errors.

1.3.5 Coding Errors

Many errors can occur in the construction of software. McConnell (2004) [MCC 04] devotes a substantial part of his book “Code Complete” to describing effective techniques for creating quality source code. He describes common programming errors and inefficiencies. According to McConnell, the typical programming errors are:

• – inappropriate choice of programming language and conventions;
• – not addressing how to manage complexity from the onset;
• – poor understanding/interpretation of design documents;
• – incoherent abstractions;
• – loop and condition errors;
• – data processing errors;
• – processing sequence errors;
• – lack of or poor validation of data upon input;
• – poor design of business rule criteria;
• – omission of transaction statuses that are required to truly represent the client process;
• – failure to process errors and illegal operations, which enables the software to process cases that would not exist in the client's sector of business;
• – poor assignment or processing of the data type;
• – error in loop or interfering with the loop index;
• – lack of skills in dealing with extremely complex nestings;
• – integer division problem;
• – poor initialization of a variable or pointer;
• – source code that does not trace back to design;
• – confusion regarding an alias for global data (global variable passed on to a subprogram).

1.3.6 Non-Compliance with Current Processes/Procedures

Some organizations have their own internal methodology and internal standards for developing/acquiring software. This internal methodology describes processes, procedures, steps, deliverables, templates, and standards (e.g., coding standard) that must be considered for software acquisition, development, maintenance, and operations. Of course, in a less mature organization, these processes/procedures will not be clearly defined.

We can therefore ask ourselves the following question: How can not fulfilling the requirements related to an internal methodology lead to defects in software? We must think in terms of the total life cycle (e.g., over many decades for subways and commercial airplanes) of the software, and not just of its initial development. It is clear that someone who only programs code appears to be far more productive than someone who develops intermediary products, such as requirements, test plans, and user documentation, as prescribed by the internal methodology of an organization. However, the immediate productivity would be disadvantageous in the long run.

Undocumented software will give rise to the following problems sooner or later:

• – When members of the software team need to coordinate their work, they will have difficulty understanding and testing poorly documented or undocumented software.
• – The person who replaces or maintains the software will only have the source code as a reference.
• – SQA will find a large number of non-conformities (with respect to the internal methodology) regarding this software.
• – The test team will have problems developing test plans and scenarios, primarily because the specifications are not available.

1.3.7 Inadequate Reviews and Tests

The purpose of software reviews and tests is to identify and check that errors and defects have been eliminated from the software. If these activities are not effective, the software delivered to the client will likely be prone to failure.

All kinds of issues can crop up when reviewing and testing software:

• – reviews only cover a very small part of the software's intermediate deliverables;
• – reviews do not identify all errors found in the documentation and software code;
• – the list of recommendations stemming from reviews is not implemented or followed up on adequately;
• – incomplete test plans do not adequately cover the entire set of functions of the software, leaving parts untested;
• – the project plan has not left much time to perform reviews or tests. In some cases, this step is shortened because it is wedged between coding and the final delivery. Delays in the early steps of the project do not always mean the delivery date will be extended, to the detriment of proper testing;
• – the testing process does not correctly report the errors or defects found;
• – the defects found are corrected, but are not subject to adequate regression testing (i.e., retesting the complete corrected software) thereafter.

1.3.8 Documentation Errors

It has been recognized that obsolete or incomplete documentation for software being used in an organization is a common problem. Few development teams enjoy spending time preparing and reviewing documentation.

We would be inclined to say no to the question “does software wear out?” Indeed, the 0s and 1s found in the memories do not wear out from use as with hardware. In addition to classifying types of errors, it is important to understand the typical reliability curve for software. Figure 1.5 describes the reliability curve for computer hardware as a function of time. This curve is called a U-shaped or bathtub curve. It represents the reliability of a piece of equipment, such as a car, throughout its life cycle.

With regard to software, the reliability curve resembles more of what is shown in Figure 1.6. This means that software deterioration occurs over time due to, among other things, numerous changes in requirements.

In conclusion, we see that there are many sources of potential errors, and that without SQA, these defects may result in failures if not discovered.

1.6.1 Description of the Context

Medical products belong to a field known for its very high quality standards. During a mandate in the cardiology products sector, Iberle (2002) [IBE 02] used a large number of traditional practices described in software engineering manuals, for example: detailed written specifications, intensive use of inspections and reviews throughout the life cycle, and exhaustive tests for requirements. Exit criteria were created at the beginning of the project and a product could not be shipped as long as the exit criteria were not met.

In this field, a project end date can be missed by weeks and even months. These delays are acceptable in order to fix any last-minute problems using a long checklist. It was far from painless. Iberle (2002) [IBE 02] explains that she worked many extra hours to try to be on schedule (and not exceed the deadline too much). There were heated debates as to whether a specific defect should be qualified as severe (level 1 severity) or average (level 2–5 severity). However, in the end, quality always won out over the schedule.

After 8 years of working on medical products, Iberle (2002) [IBE 02] was assigned to the business sector that produced printers and served small businesses and consumers. Practices in this business sector of the company were very different. For example, specifications were far shorter, project exit criteria significantly less formal, but making the delivery date was very important. While Iberle was working in testing, she noticed differences in test practices. The main test effort was not focused on tests related to specifications. They were not trying to test all possible entry combinations. There was far less test documentation. In fact, some testers had no test procedures. This was a huge culture shock. At first, Iberle would walk around shaking her head, and grumbling “These people don't care about quality!" After a while, she started to see that her definition of quality was different and was based on her experience in a different field. It was time for her to revisit her beliefs about software quality.

1.6.2 Anxiety and Fear

When Iberle (2003) [IBE 03] worked on defibrillators and cardiographs, missing a delivery date was not the worst thing that could happen. What really scared the team was what could kill a patient or technician due to an electrical shock, cause a person to come to the wrong diagnosis, or that the device could not be used in an emergency situation. If the team raised the possibility of a failure, the delivery date was automatically pushed forward, without any discussion whatsoever. Lengthy and costly efforts to find and definitely eliminate the cause of the defect were systematically approved. It was obvious that, for an organization in this business sector, shirking one's legal responsibility or being blamed by the American Food and Drug Administration definitely contributed to these decisions. Delivery dates could be changed and production completed with overtime.

In the consumer products division, the reality was quite different. The potential for injury was very low, even in the worst conditions imaginable. The real concern was not respecting schedules or exceeding costs. When software has to be packaged in hundreds of thousands of boxes and these boxes must be sent to resellers on time for the day of a major sale, there is not much room to “play catch up.” Another fear was having thousands of users unable to install their new printer and calling customer support lines the day after Christmas. Incompatibility between the most popular software and hardware was another source of concern.

So these two business divisions had different definitions of “quality.” Clients valued different things: clients from the medical sector favored accuracy and reliability above all, whereas printer customers looked for user-friendliness and compatibility far more than reliability. Of course, everyone wants reliability. However, whether they are aware of it or not, people value reliability as a function of the pain that certain problems may cause them. People are not happy when they have to restart their computer from time to time, but their misfortune is nothing in comparison with the anguish of a patient faced with a functional problem with a heart defibrillator. When someone goes into fibrillation, there is a 5–6 minute window for saving the patient. So there is no time to lose with equipment problems.

The definition of “reliability” is therefore also very different in these two business sectors. When it was understood that no one would die from a printer software error, the team examined the software practices in the medical products division to determine whether they were also useful in the printer sector [IBE 03]. It would take Iberle several months to realize that what seemed shoddy in the printer sector was a way of dealing with different priorities that did not carry the same weight as for medical products.

1.6.3 Choice of Software Practices

As expected, people from both business sectors chose software engineering practices that would lower the probability of their worst fears. Since their apprehensions are different, their practices are also different. In fact, in light of their fears, the choice of practices starts to make sense. The fear of a false diagnosis leads to many detailed reviews and various types of tests. However, the fear of confusing printer users results in more usability tests.

It is not surprising to see that people who work in the same business sectors have similar concerns and use similar practices. Certain concerns can also be found in other organizations. For example, the aerospace sector and medical sector are very closely related. It is also possible for the same organization to have different fears and values in different business sectors, as Iberle (2003) [IBE 03] described above of her employment at Hewlett-Packard.

Software organizations or software specialists are divided into groups that appreciate similar things or share the same concerns, based on similarities in client and business community expectations. These cultures are called “practice groups,” that is, software development groups, which share common definitions of quality and tend to use similar practices.

1.6.4 Business Model Descriptions

The following models were developed by Iberle to better understand the need for QA in different business sectors, given that the way in which money flows through an organization (e.g., contract income, cost of products delivered, and losses) and how profits are generated affect the choice of the software practices used to develop products for an organization. The five main business models in the software industry are [IBE 03]:

• – Custom systems written on contract: The organization makes profits by selling tailored software development services for clients (e.g., Accenture, TATA, and Infosys).
• – Custom software written in-house: The organization develops software to improve organizational efficiency (e.g., your current internal IT organization).
• – Commercial software: The company makes profits by developing and selling software to other organizations (e.g., Oracle and SAP).
• – Mass-market software: The company makes profits by developing and selling software to consumers (e.g., Microsoft and Adobe).
• – Commercial and mass-market firmware: The company makes profits by selling software in embedded hardware and systems (e.g., digital cameras, automobile braking system, and airplane engines).

1.6.5 Description of Generic Situational Factors

Each business model has a set of attributes or factors that are specific to it. Here is a list of situational factors that seem to influence the choice of software engineering practices in general [IBE 03]:

• – Criticality: The potential to cause harm to the user or prejudice the interests of the purchaser varies depending on the type of product. Some software may kill a person if it shuts down; other software programs may result in major money losses for many people; others will make a user waste time.
• – Uncertainty of users’ wants and needs: The requirements for software that implements a familiar process in an organization are better known than the requirements for a consumer product that is so new that the end-users do not even know what they want.
• – Range of environments: Software written for use in a specific organization only has to be compatible with its own computer environment, whereas software sold to a mass market must work in a wide range of environments.
• – Cost of fixing errors: Distributing corrections for certain software applications (e.g., embedded software of an automobile) is usually far more costly than fixing a website.
• – Regulations: Regulatory bodies and contractual clauses may require the use of software practices other than those that would normally be adopted. Certain situations require process audits to check whether a process was followed at the time of producing the software.
• – Project size: Projects that take several years and require hundreds of developers are common in certain organizations, whereas in other organizations, shorter projects developed by a single team are more typical.
• – Communication: There are a certain number of factors, in addition to project scope, that can increase the quantity of person-to-person communication or make communications more difficult. Certain factors seem to occur more often within certain cultures, whereas others happen at random:

• Concurrent developer–developer communication: Communication with other people on the same project is affected by the way in which the work is distributed. In certain organizations, senior engineers design the software and junior staff carries out the coding and unit tests (instead of having the same person carrying out the design, coding, and unit tests for a given component). This practice increases the quantity of communications between developers.
• Developer–maintainer communication: Maintenance and enhancements require communication with the developers. Communication with developers is greatly facilitated when they work in the same area.
• Communication between managers and developers: Progress reports must be sent to upper management. However, the quantity of information and form of communication that managers believe they need may vary substantially.

• – Organization's culture: The organization has a culture that defines how people work. There are four types of organizational cultures:

• Control culture: control cultures, such as IBM and GE, are motivated by the need for power and security.
• Skill culture: A culture of skill is defined by the need to make full use of one's skills: Microsoft is a good example.
• Collaborative culture: A collaborative culture, as illustrated by Hewlett-Packard, is motivated by a need to belong.
• Thriving culture: A thriving culture is motivated by self-actualization, and can be seen in start-up organizations.

1.6.6 Detailed Description of Each Business Model

This section goes into more detail about each of the five main business models. A single business model, contract-based development for made-to-measure systems, is described as an in-depth case study. For this business model, we describe the following four perspectives:

• – context;
• – situational factors;
• – concerns; and
• – software practices predominately used in this business model.

For the other four business models, we will only consider the context and concerns.

1.8 Further Reading

1. ARTHUR L. J. Improving Software Quality: An Insider's Guide to TQM. John Wiley & Sons, New York, 1992, 320 p.
2. CROSBY P. B. Quality Is Free. McGraw-Hill, New York, 1979, 309 p.
3. DEMING W. E. Out of the Crisis. MIT Press, Cambridge, MA, 2000, 524 p.
4. HUMPHREY W. S. Managing the Software Process. Addison-Wesley, Reading, MA, 1989, Chapters 8, 10, and 16.
5. JURAN J. M. Juran on Leadership for Quality. The Free Press, New York, 1989.
6. SURYN W., ABRAN A., and APRIL A. ISO/IEC SQuaRE. The Second Generation of Standards for Software Product Quality. In: Proceedings of the 7th IASTED international conference on Software Engineering and Applications (ICSEA'03), Montreal, Canada, 2003, pp. 1–9.
7. VINCENTI W. G. What Engineers Know and How They Know It—Analytical Studies from Aeronautical History. John Hopkins University Press, Baltimore, MD, 1993, 336 p.