Download the Article (PDF, 82 KB)
Patricia Rodríguez-Dapena, Independent
with: T. Vardanega, European Space Agency; J. Trienekens and A. Brombacher, Eindhoven Technical University; and J. Gutierrez-Rios, Politechnical University of Madrid
Safety, reliability, reusability, and portability are among the most prominent nonfunctional requirements at the system and software level. They are becoming both the focus of consumers and the market drivers of producers. How are nonfunctional requirements engineered into the system and how are they verified? All too often they are too vaguely expressed or exceedingly difficult to implement, or emerge too late in the development. This article addresses the complex challenge of constructing software-intensive systems while thoroughly integrating the development and verification of nonfunctional requirements. The author puts the challenge into perspective by detailing the factors that influence the development of nonfunctional requirements and, using a classical "divide-and-conquer" approach, breaking the original problem into smaller problems, thereby trying to contain and control the risks that may jeopardize the success of the project.
Key words: requirements management, software characteristics, software development processes, software intensive systems
Most practitioners know firsthand that the development of software intensive systems is a particularly complex endeavor, for it involves a variety of tough challenges. Many software system projects fail in various respects. Several international reports, such as the European Commission Survey (ESI 1997), as well as various experts (Boehm, Port, and Al-Said 2000), analyze the possible causes of so many failures. Yet the layman question stands: "Why are so many software systems shipped late, in great budget overruns, and perhaps without even being used operationally?" Factors such as floating user requirements, poor quality levels, schedule and budget pressure, and low efficiency of developers are the typical challenges that several national and international initiatives acknowledge and want to master.
The success of a project entails much more than correctly implementing the given functional requirements with a known development process on time and within budget. Project requirements originate from operational users, ordering customers, developer organizations, and so on, and they relate to both the product and its development process.
Years ago focus was put on the analysis of the development process issue. Several projects were launched by the European Union, such as the European Systems Software Initiative (ESSI 1993), and multiple international standards such as ISO 12207 (1995), and ISO 15504 (1999) were defined to increase the effectiveness of the software practices related to the development of generic product requirements. As a result, important progress was achieved in this area. Some software best practices now exist as consolidated reference for practitioners to consider and share. Yet projects face increasingly difficult challenges while the market becomes more competitive and time and resource budgets become increasingly tighter.
The heart of the matter, arguably, is that product requirements originate from multiple, often independent, sources, which represent differing perspectives-primarily those of users, customers, and developers. Software intensive systems have to meet functional requirements that constitute the "classical" set of explicit requirements and correspond to the "what" is to be done by the software and where it will run (that is, functional, operational, interface, and other requirements). Software intensive systems have other requirements to meet also, which often are fuzzy or genuinely unknown at the beginning of the development processes. These other requirements concern "how" those functions must be performed (that is, performance, resources, user interaction, safety, reliability, and so on). They are normally referred to as nonfunctional requirements or characteristics, and have been viewed as the cause of many software project failures (Neumann 2001).
One example could be the McIntosh-Prescott report to the Australian government concerning the problems with its new Collins class submarine project. It noted major problems with the new submarines, including unreliable diesel engines, excessive noise, cracking propellers, and poor communications and periscope vision. Deficiencies in project management and procurement were also criticized. The hardware issues, though serious, could be fixed, but the software for the combat system was considered unlikely to ever work. The major conclusion of the report, however, was to completely dump the software and start again (at a huge cost) (Neumann 2001).
What is the meaning of poor communication? Not being involved in the development or evaluation of this system one could argue that the poor communication could be either a customer perception, not having specified the required efficiency of this functionality, or due to an improper system implementation and verification. Do developers consider "software productivity" or "software efficiency" as part of their requirements when developing software? How can they engineer "software usability," defined as "the extent to which the software can be understood, learned, operated, is attractive and compliant with usability regulations and guidelines"(ISO 9126 1992)?
To better understand the nature of these nonfunctional requirements and the way they could be implemented in software, the author uses the classical approach of dividing the problem into smaller subproblems. (In the following, the terms "characteristic" and "nonfunctional requirement" are used interchangeably.)
CURRENT STATUS OF IMPLEMENTING NONFUNCTIONAL REQUIREMENTS
The difficulty with nonfunctional requirements starts at the beginning of the software development process:
Experience shows that several nonfunctional requirements are not properly defined at the beginning of the software development process. Consider, for instance, how frequently users or customers reject a system because they dislike the look and feel of the user interface, or because they realize that portability is more important to the system than initially anticipated. Users and customers strive to have all of their requirements defined in time, but often they can only achieve this for functional requirements. Spiral or evolutionary development life cycles help in coping with the uncertainty of such situations. Yet the problem surfaces again when late requirements arise that are critical to acceptance but are hard to reengineer in the product within reasonable cost and resource envelopes. As a matter of fact, these late requirements often concern nonfunctional characteristics of the product such as reliability and portability. The study of characteristics is still evolving, and there are limitations in their definition and development.
Even when top-level system requirements have been fully and exhaustively captured, transferring the nonfunctional requirements to software development is not necessarily obvious and straightforward. One may wonder, for example, how reliability or safety characteristics based on probabilities can properly translate to software requirements.
Expressing nonfunctional requirements in terms of prescriptions that are understandable, complete, and simple for engineers to implement and verify is difficult. Too often nonfunctional requirements cannot be expressed quantitatively, owing to the lack of standardized definitions and insufficient experience with their implementation and verification. Expressing those requirements qualitatively is not the solution because it exposes the project to the risk of misunderstandings and misinterpretations.
Most current requirements engineering methods are limited since they are highly restricted in scope and provide little support for capturing nonfunctional requirements and information about the environment in which the software will run. More work is required in this area to ensure that the development is based on a complete and consistent set of requirements.
As a matter of fact, it is almost always impractical to implement requirements engineering as a linear, deterministic process where system requirements are elicited from the customers, users, and so on, baselined, allocated, and handed over to the software development team. It is usual that the requirements are not completely understood nor adequately specified before all their properties and implications are fully appreciated. This is not desirable, but it is often a fact of life in the face of tight schedules. For example, developers are often faced with baseline requirements calling for the implementation of probability-based reliability or safety attributes. Requirements of this kind are difficult to interpret for software, and they may also significantly impact the product architecture. As a further example, the requirements related to the usability characteristic defined previously in ISO 9126 (1992) typically interact with other lower-level ones such as learnability, and understandability, the definition of which is still the subject of debate.
While these situations cannot be completely eradicated, the author will try to minimize the ensuing risk of project jeopardy by using prevention and compensation techniques while these characteristics are being implemented. This article presents an announcement of concern to software professionals, and provides a process-oriented proposal of how these characteristics could be systematically engineered and verified along the software life cycle.
Characteristics: Engineering Process
Like functional requirements, nonfunctional requirements generally allow multiple implementation strategies, which often are inherently multidisciplinary. Some strategies involve the adoption of and adherence to specific implementation rules, while others demand the use of compliant infrastructures. Others entail the use of domain-specific architectures, and still others require a combination of these. At any rate, the implementation strategy designed to satisfy nonfunctional requirements must be planned well in advance and needs adequate support. This provision further requires system-level understanding and analysis because requirements from different origin may occasionally generate conflicting needs, which must be resolved with the "system hat on."
Characteristics: Verification and Validation
The implementation of nonfunctional requirements is often difficult to verify and validate. Inherent technical limitations and genuine technical difficulties tend to reduce the capability and coverage of the support infrastructure. Too many different scenarios to test and too many different input combinations for the functions and characteristics to be verified compel the developer to prioritize the limited set of tests to be performed with the budget and timing constraints for each project. In fact, nonfunctional requirements are often the first ones to bypass systematic verification.
Unfortunately, international development standards still do not incorporate engineering, verification, and validation processes specifically suited for the treatment of characteristics. It may be that these characteristic-related processes, which have a distinct domain-specific birthmark (notably nuclear and avionics), are still being perceived as too domain-specific to make generic reference models or generic life cycles. But, in fact, the exponential software penetration of commerce, banking, and telecommunication services makes public and private interest demand for the addition of specific characteristics (for example, performance and usability) into the set of crucial acceptance criteria.
In this article the author proposes a standard process definition applicable to any characteristic, formulates recommendations on how each activity should be performed, and singles out examples of several issues (mostly technology specific) that remain open for investigation.
The author also looks into how characteristics are implemented in the software component(s) of complex systems. The conclusions she draws from this analysis should easily apply by analogy to nonsoftware components and the system overall.
NOMINAL DEVELOPMENT PROCESS
Throughout this article the author calls "nominal" processes the technical processes aimed at the implementation of functional requirements. This is a way to differentiate them from those processes that aim at the implementation of characteristics. The notion of nominal development processes is used to determine how the development of characteristics could best fit within them.
ISO 15288 (2000) defines every system to have a life cycle that begins with a concept; progresses through its development, utilization, and evolution; and ends in its retirement. This progression is achieved as the result of processes applied, performed, and managed by individuals within concerned organizations.
A distinction is usually drawn between the set of processes that are specific to the organization and the set of processes that are specific to individual projects within the organization. The latter set typically includes development or technical processes and management processes, where the technical processes further include two main streamlines-the engineering processes and verification processes.
In principle, all the processes depicted in Figure 1 could be carried out in full parallelism. The specific purpose and order of execution of these processes throughout the life cycle is determined for each project by multiple factors, including specific application domain constraints, and organizational and technical considerations, which may vary during the life of a system. It is when a project is defined that the constraints in time, responsibilities, resources, and system objectives arise to bound the extent of this process concurrency.
Irrespective of the potential parallelism of individual
processes, the life cycle of any system progresses through
an underlying set of stages. Each stage has a distinct
purpose and contribution to the whole life cycle, which should
be thoroughly considered when planning and executing the system
life cycle. These stages allow developing or user organizations
to measure the rate and success of progress and to prevent
uncertainties and risks associated with cost, schedule, and
functionality. Most of the existing development standards
use these stages to set out the activities encompassed in
the development of a (software)
Figure 2 depicts the relationship between system development and the software engineering stages. Hardware stages and human procedure definition life cycles are also composed of engineering processes that proceed in parallel to the software ones. The diagram, however, might become too complex to represent if one also wanted to draw the missing management and verification processes for both the system and each lower-level subsystem and component. The complexity implied by Figure 2 is only a glimpse of the challenge system engineers face in managing all of the processes needed to build the required system within budget and schedule.
Functional requirements constitute the usual set of system requirements, which are implemented upon the execution of specific development processes. As shown in Figure 2, these system requirements are subsequently analyzed, transferred to, and implemented by the different subsystems (including software), the products of which integrate to compose the system ultimately delivered for operation.
The crucial question is how to ensure the effective implementation of characteristics into a complex system without the management complexity arising from the addition of dedicated processes growing beyond control.
SOFTWARE CHARACTERISTICS: DEFINITION
ISO 9000 (2000) defines the notion of characteristic as "related to needs and expectations." It then provides a taxonomy of various classes of quality characteristic, such as:
Looking at how the literature and the relevant international standards define and engineer these characteristics, the author is unable to infer a sufficiently harmonized process.
ISO 9126 (1992) defines top-level software quality characteristics in general and then breaks them into lower-level software subcharacteristics and associated metrics. This reflects the fact that ISO 9126 mainly focuses on late measurements and verifications of the software product rather than on discussing how these quality characteristics should be specified and engineered. Other standards, for example, ISO 12207 (1995), do not contemplate the notion of characteristics yet and treat all requirements as one undistinguished set. A further set of standards, such as IEC 61508 (1999) and (MOD 1997) only focus on one specific characteristic (safety), and some of them, for example, IEC 60300 (1997) do not really explain how the corresponding implementation systematically interacts and integrates with the other requirements.
From this rapid analysis of the specialized literature and of the most important international standards one can only conclude that the definition and engineering of characteristics are still far from featuring a well-harmonized notion and associated process(es). As mentioned earlier, one reason could be that these characteristics are a still-evolving notion and that they are not well defined.
From an analysis of the literature, software characteristics or nonfunctional requirements may be divided into two broad groups:
The latter group of characteristics may in turn be classified in two subgroups:
Explicit characteristics should always be defined at the beginning of the software development process (the concept stage). Users and customers should define their requirements before starting the development process. International standards such as ISO 9126 list many of these explicit or top-level characteristics that could be used as a checklist to capture user-level and customer-level nonfunctional requirements. The author regards the other implicit characteristics as "pure" software characteristics, which should be defined at the software requirements stage and/or when the technology and architecture of the software product are known.
How can one make sure that he or she has defined the complete set of characteristics for the software product? This question is difficult to answer, but by using the aforementioned checklist (for example, using the list provided in ISO 9126 as a reference) to perform the requirements capture, one expects he or she should be able to get more of these nonfunctional requirements and better plan the development processes.
SOFTWARE CHARACTERISTIC DEVELOPMENT PROCESSES
This article will now define the technical processes required for the engineering and verification of characteristics and the way they should be integrated within the current nominal development processes.
Can these processes be the same as those used for the implementation of functional requirements? What is the best way to facilitate the proper definition, implementation, and verification of these characteristics from the management standpoint?
These characteristic development processes consist of several activities (primarily concerned with planning, engineering, and verification) to perform either in parallel to or in conjunction with the nominal processes.
Although there is nothing generally precluding full integration of functional and nonfunctional processes, the need to preserve the independence of the responsibility line (and often that of expertise) involved by the respective processes suggests keeping some separation between them. Preserving the independence of an activity or a process is also an effective way of sanctioning its importance. Mingling safety responsibilities and concerns was in the past the cause of several catastrophic accidents. The recognition of how the "human factor" contributes to this phenomenon prompted the definition of specific development requirements on the independent verification of safety characteristics.
A parallel approach for the development and verification of characteristics might be beneficial in two respects:
Having a dedicated parallel process for each characteristic, however, is not realistic, affordable, or manageable because of the ensuing increase in complexity. Integration within nominal processes is therefore desirable (and even necessary) for some characteristics (especially the implicit ones and some explicit ones such as portability), but separation and parallelism should be preserved for the characteristics with greater impact on the system.
In order to formalize the process designed for the implementation of software characteristics, the author uses the format for reference process descriptions defined in ISO 15504 (1999), which requires one to provide:
A process is further subdivided by collating the functions of it more cohesively into groups called activities. Each activity follows the plan-do-check-act (PDCA) philosophy (Noguchi 1995). The PDCA cycle, even if originally intended to introduce the concept of continuous process improvement, fits the author's purpose here insofar as it can be used to prompt, guide, and control iterations within a process and across processes in a wider scope (see for example, the adapted cycle in Figure 3).
In its original definition (Noguchi 1995), the PDCA cycle begins with a plan for improving an activity. Once the improvement plan is completed, the plan is implemented, the results are checked, and actions are taken to correct deviations. In this article, the author adapts this cycle to the definition of the activities of a life-cycle process. For our process cycle therefore, any process begins with a plan or strategy definition for the execution of the concerned activities (plan process). Once the plan definition is completed, the plan is executed, which entails executing the engineering activities of the process (engineering activities). Results are then checked, which corresponds to the execution of specific verification activities, and actions are taken to correct deviations, in which case the cycle is repeated (improve process). If the implementation produced the desired results, actions are taken to make the product change permanent.
In view of this, one could formally define the software characteristic process as follows:
Process-set name: Software characteristic process
Process purpose: The purpose of the software characteristic process is to implement the characteristics derived from system-level requirements and constraints and to verify that each software work product and/or service of a process properly reflects those characteristics and, consequently, the originating requirements and constraints.
Process outcomes: Successful implementation of this process will result in:
1. The definition of a software engineering and verification strategy (plan)
2. The execution of required characteristic-related activities (do)
3. The identification and removal of defects from software work products (check and act)
The aforementioned PDCA cycle may apply for each stage for each individual characteristic. The processes concerned with top-level characteristics could proceed in parallel to the nominal development processes, which is more or less what currently happens for characteristics like safety and reliability. For lower-level characteristics the author recommends integration within the nominal development process. Each software stage should thus proceed across the PDCA cycle for each applicable characteristic, as one should do for each nominal development process.
Figure 4 portrays an example of the interaction between the engineering of one software characteristic (safety in this case) and the different software stages of the nominal development processes under the extreme assumption that all the concerned engineering and verification activities be performed in parallel. This extent of parallelism might suggest effort duplication for each characteristic to implement, but system (and software) characteristics are, of course, significantly less in number and volume than the nominal functional requirements. In fact, all that the diagram in Figure 4 wants to emphasize is the need to carefully plan the engineering of every characteristic applicable to the project.
The need for dedicated parallel processes has been fully recognized for top-level characteristics such as safety and reliability. The same has not yet occurred, however, for other characteristics (such as predictability, portability, or maintainability) that are equally important to the success of the system, but perhaps not as visible to the user.
Low-level characteristics also must be carefully planned for and controlled for the success of the project. Consider an example of these low-level characteristics, namely real-time performance characteristics such as predictability, which are becoming increasingly important in a variety of application domains. These characteristics are not precisely defined at the start of the development since they depend on the technology and software architecture to be used, but they should become crucial for developers at implementation phases, since the operability of the software product depends on them. Full understanding of the need for well-defined engineering and verification processes for these low-level characteristics is slowly emerging. Vardanega (1998) and ECSS (2001) discuss the development of real-time space on-board systems.
Figure 5 represents the view promoted by these references by depicting the main real-time activities in relation to the nominal engineering ones. The characteristic-related processes are drawn as parallel processes only for planning and clarity reasons, but they may be integrated with the nominal ones once their detailed planning is defined for each project.
The integration of the whole range of characteristic-related processes within a system development, and thus within all of its subsystems, is a complex N-dimensional issue, which inevitably presents significant management challenges. Think, for example, of the considerable cost and risk associated with the control and coordination of multiple lower-level developments. Exceeding management complexity may jeopardize the quality and success of the project. The author believes one can tackle this challenge by proposing project managers: 1) a set of standard parallel processes specifically related to critical characteristics; and 2) the integration of engineering and verification of other characteristics into the nominal processes.
The scheme outlined previously should facilitate the planning of characteristic-related processes and their execution in concurrency with each software life-cycle process. Systematically following the author's adapted PDCA approach for each characteristic to be implemented, at each software stage, one must plan for:
As all these items are duly planned for each activity, one can identify and plan the project needs as well as identify risks and assess them. The availability of enabling technology determines the level of performance and the extent of implementation achievable for characteristic processes. Compromises may be needed when competing or conflicting characteristics pull the development toward different engineering directions.
Each development stage will inevitably bear its own share of problems related to the implementation of individual characteristics. By identifying them in advance one can hope to better control and manage the project.
The following briefly addresses problems that might arise at specific stages of software projects when planning for the implementation of, say, safety and reliability characteristics. Several other problems and questions may need to be addressed when planning the implementation of other characteristics. All missing answers still obviously constitute potential project hazards, but by being known problems, they should be considerably smaller and more controllable.
Safety and reliability are very difficult to define precisely. Imprecise definitions may lead to inaccurate decisions. The definition and analysis of the system behavioral space shall receive attention from early in the system (and in the software) life cycle.
The way system requirements on safety and reliability translate to software requirements is of paramount importance. What are the design and implementation constraints derived from the system requirements or from the system criticality analyses? What software criticality verification methods, techniques, and reporting procedures aid in demonstrating that the final system will be safe and that no software fault will be the cause of a catastrophic consequence? Does one need specially skilled personnel to help in the translation of system requirements to software nonfunctional requirements? Techniques that support the derivation of software requirements from system-level requirements are a major area of research. Proper answers to questions like these are crucial to the development of increasingly software-intensive complex systems.
Leveson (1995) argues that a range of major software faults originated from badly specified software product-related requirements. Software design errors may be traced to wrong or incomplete software specifications resulting from higher system design errors (which may be hard to uncover).
Most of the current requirements engineering methods provide limited support to the capture of characteristics and information about the actual execution environment. Further work is required in this area to enable the capture and model a complete and a consistent set of software safety and reliability requirements.
Design, Implementation, Integration, and Test
Further effort is required to assess the cost/performance ratio of specific design and implementation techniques and mechanisms for the implementation of characteristics. For example, the state of the art in the industrial production of devices and procedures to mitigate software system hazards is still largely inadequate. Standards calling for specific implementation of characteristics require further validation through use.
Verification and Validation
Verification should be performed in parallel to the system (or subsystem) development activities to warrant that no mistakes are made or at least that none is overlooked (see, for example, Figure 4 in which analysis boxes are placed parallel to the corresponding software development phase). Certain characteristics (again, like safety and reliability) do not possess clear verification methods usable at early engineering stages.
Since exhaustive testing is not an option for realistic systems, static methods and techniques must be used for the verification and validation of the software products (see, for example, the software safety analysis included in Figure 4). The verification activities required or recommended for each software development phase vary among standards and application domains, specifically in what concerns the verification and validation of safety and reliability characteristics. For example, formal arguments to demonstrate that the object code satisfies the formal specification are required by the U. K. Ministry of Defence (DEF STD 00-55 1997) to meet safety requirements, but they are not by other standards (for example, RTCA 1992; ECSS 2001). RTCA (1992) specifies a difficult and expensive set of process requirements to ensure that software code does not incur run-time errors for all test methods proposed. The cost/benefit ratio of this approach must be substantiated for other (less demanding) standards to consider the option. Research investigations are necessary in order to demonstrate that well-known static analysis techniques used to verify safety and reliability in the hardware domain are useful to apply in the software arena, along with insight on how they should be applied.
Software/Hardware Integration and Validation
Embedded applications require special attention (and specific activities) when performing integration with the final hardware. Some of the system requirements may not have been verified prior to the integration phase. The net consequence of this is that those requirements would have to be tested in the final target environment and, often, only at a black-box level. Specific test facilities are usually needed for the final integration and validation of embedded software. Those facilities, however, are still very much ad hoc and tend to be insufficiently equipped for the verification of all the characteristics that were not verified earlier in the development stages and often hard (if not impossible) to verify by testing. Other analysis methods (such as static methods) are needed instead.
Current-generation systems of medium to high complexity have to meet functional requirements along with other specific characteristics (often called nonfunctional requirements). Those characteristics include, for example, safety, reliability, reusability, predictability, portability, and the like. Characteristics are an important (if not essential) component of user requirements. Oddly enough, however, characteristics are often insufficiently defined, implemented, or verified, thereby presenting a serious threat to project success.
The development processes of characteristics may to a large extent proceed in parallel to the execution of the nominal development. A systematic process planning definition that contemplates both functional and nonfunctional requirements facilitates the execution and the control of those parallel processes. This article has addressed the complexity of developing software intensive systems and has outlined a management strategy that enables the definition and execution of reference characteristic development processes.
Recognizing this subject is still evolving, international standards should desirably recognize this phenomenon soon and equip themselves to assist practitioners in the development and verification of characteristics. Future versions of ISO 12207 (1995) should include new software processes in the category of primary life-cycle process (that is, those processes to be performed by both the customer and the supplier). These processes should be intended to both engineer and verify the characteristics demanded of software products. These processes should be defined not only for software but also for the system life cycle. The verification activities should focus not only on numerical data, but also contemplate other analysis methods that allow the verification of all the characteristics required of the system. The state of the art in quantitative measures for both the definition and verification of characteristics has vast room for improvement. Undoubtedly more effort will be required of standards-writing working groups to steer the definition and incorporation of characteristic-related processes in standard life cycles.
Boehm, B., D. Port, and M. Al-Said. 2000. Avoiding the software model clash spiderweb. IEEE Computer 33, no. 11 (November).
DEF STD 00-55: Requirements for safety-related software defence equipment, parts 1 and 2, issue 2. 1997. U. K. Ministry of Defence. See URL www.dstan.mod.uk/dstan_data/ix-00.htm .
European Cooperation for Space Standardization (ECSS). 2001. ECSS standards series. European Space Agency Publications. See URL www.esa.nl/ecss/ .
European Software Institute (ESI). 1997. Report on the 1995/1996 software excellence survey. Bilbao, Spain: European Software Institute.
ESSI. 1993. European Systems and Software Initiative, ESSI 2, fourth framework program. Brussels: European Communities. See URL www.cordis.lu/en/src/f_002_en.htm/
IEC 60300: Dependability management, parts 1-3.1997. Geneva, Switzerland: International Electrotechnical Commission.
IEC 61508: Functional safety: safety-related system, parts 1-7. 1999. Geneva, Switzerland: International Electrotechnical Commission.
ISO/IEC 12207: Information technology - software life-cycle processes. 1995. Geneva, Switzerland: International Organization for Standardization.
ISO/IEC Technical Report 15504:1999, parts 1-9, Information technology - Software process assessment. 1999. Geneva, Switzerland: International Organization for Standardization. Also see URL www.iso.ch.
ISO/IEC 9000:2000 Quality management systems - fundamentals and vocabulary. 2000. Geneva, Switzerland: International Organization for Standardization. Also see URL www.iso.ch.
ISO/IEC CD 15288.3 Information technology -Life-cycle management -System life-cycle processes. (ISO/JTC 1/SC 7 N2425). 2000. Geneva, Switzerland: International Organization for Standardization. Also see URL saturne.info.uqam.ca/Labo_Recherche/Lrgl/sc7/.
ISO/IEC 9126: Information technology - Software product quality. 1992. Geneva, Switzerland: International Organization for Standardization.
Leveson, N. G. 1995. Safeware system safety and computers. Reading, Mass.: Addison-Wesley.
Neumann, P. G. 2001. Computer related risks. See URL catless.ncl.ac.uk/Risks.
Noguchi, J. 1995. The legacy of W. Edwards Deming. Quality Progress 28, no. 12 (December).
Requirements and Technical Concepts for Avionics (RTCA). 1992. Software considerations in airborne systems and equipment certification, Document NO RTCA/DO-178B. Washington, D. C.: RTCA.
Vardanega, T. 1998. Development of on-board real-time systems: An engineering approach. Ph.D. thesis. Technical University of Delft.
Voas, J. 1999. Certifying software for high assurance environments. IEEE Software 14, no.4 (July/August). Also see URL www.cigitallabs.com/cgi-bin/DB_Search/db_search.cgi.
Patricia Rodriguez-Dapena is currently the owner and president of SoftWCare S. L. The company works in the areas of software safety and reliability evaluation and in the software process assessment. She was a software product assurance engineer and a software engineer at the European Space Agency in The Netherlands from 1992 to 2000. Her main interest is software engineering and verification for software in safety critical systems. Rodriguez-Dapena is also interested in software engineering standardization and software process modeling, implementation, and software process assessment models. She has been employed in the software industry in Spain since 1987 and has worked as a programmer, analyst, and researcher.
Rodriguez-Dapena received a master's degree in computer science from the Politechnical University of Madrid in 1987 and is currently finishing her doctorate thesis at the Technical University of Eindhoven in The Netherlands. She can be reached at: SoftWcare S.L., Serafín Avendaño 18 Int. Oficina 13, 36201 Vigo (Pontevedra) Spain or by e-mail at firstname.lastname@example.org
If you liked this article, subscribe now.