In a previous paper (Eleiche, 2010), it was concluded that in order to support innovative energy research projects funded by the CCWCE (2008), innovators should be provided with a software program that can help manage the effects of possible changes in design requirements (DR) and hence facilitate the design of successful quality systems on schedule and within planned budgets. It was also stated that guidance would be sought from similar research being carried out in the software engineering arena.

In the present paper, we address in detail the subject of DR, which is central to the design of software and engineering systems. The main reason for this is that quality aspects are usually closely tied to requirements, among other things. In this review paper, we consider how the subject of requirements is being managed in these two seemingly different disciplines. Two important aspects are covered, namely: (a) requirements development, describing various activities leading to re-quirements documentation, and (b) requirements change management, describing various activities needed for the proper treatment of the inevitable changes in requi-rements. Similarities and differences on how these two aspects are handled in software and engineering systems are highlighted. Important gaps and future important research areas are also identified.

The next section introduces the topics related to DR. in a generic way. This is followed in Section 3 by an overview of how DR development is treated in software and engineering systems, while Section 4 presents how DR management is being applied in these same two disciplines. Important conclusions are given finally in Section 5.

IEEE (1990) defines “Requirement” as a condition or capability that: (a) is needed by a user to solve a problem or achieve an objective, (b) must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component.

Requirements Engineering (RE) is a crucial aspect for a successful development of software and engineering systems. The RE process is the primary work of the “Requirements” phase of the project. Figure 1 shows the sub disciplines of RE (Wiegers, 2000) consisting of two major types of activities. In RE development, “User Needs” are translated into “Requirements Specification” through five activities that form a sub-process, while the activities in RE management, namely traceability and change, do not flow into each other but are separate.

Requirements can be classified into: (a) Functional requirements that capture the intended behavior in terms of services, tasks or functions the system is required to perform; (b) Non-functional requirements (or system qualities) that capture required properties or qualities of the system; (c) Constraints (organizational, operational, economical, legislative, and ethical). All requirements must be carefully derived through analysis of user needs and documented. They should specify what is to be done, not how it is to be done.

A good requirement should be (Tavassoli, 2009): clear; complete; correct; consistent; verifiable; traceable; feasible; modular; adaptable; and design-independent.

Nowhere more than in the requirements process do the interests of all the stakeholders in a software or engineering system project intersect. These include: (a) external stakeholders (end users, customers acquiring the product, suppliers, distributors, subcontractors, legislators, policy makers); and (b) internal stakeholders (requirements analysts, project managers, developers, designers, manufacturing staff, testers, regulators and auditors, sales and marketing, purchasing and finance, and field support or help desk staff). Handled well, this intersection can lead to exciting products, delighted customers, and fulfilled developers. Handled poorly, it is the source of misunderstanding, frustration, and friction that undermine the product’s quality and business value.

Many software problems arise from shortcomings in the ways that people acquire, document, agree on, and modify the product’s requirements. Typical problem areas include informal information gathering, implied functionality, inadequately defined requirements, and a casual change process (SERENA, 2011). The widely quoted CHAOS report (Standish Group, 1995) relates the consequences of casual approaches to requirements engineering. Year after year, lack of user input, incomplete requirements, and changing requirements are the major reasons why so many software and information technology projects fail to deliver all of their planned functionality on schedule and within budget.

In software engineering, RE has already been accepted as an independent discipline and is done systematically. As will be seen in the following, many concepts and methods for handling of requirements have already been elaborated. Hence, a common terminology of process phases in RD has emerged, involving elicitation, negotiation, analysis, specification and validation. This is depicted in Fig. 2, as proposed by Kotonya and Sommerville (1998).

During the requirements elicitation phase, different complementary techniques are applied to understand the application domain, and the problems and needs of all stakeholders. The most common software requirements elicitation techniques are interviewing, brainstorming, storyboarding, workshops, surveys/questionnaire, and ethnography (Braude, 2010; Lamsweerde, 2009; Press man, 2005; Sommerville, 2007; Wiegers, 2003). The full integration of users is a decisive factor for the success of this RD phase (Kujala et al., 2005).

During requirements negotiation, the elicited requirements are discussed with the stakeholders. Requirements are then prioritized, unnecessary ones are removed, and conflicting and incomplete ones are resolved. Requirements scope/baseline is also defined and agreed upon (Kotonya and Sommerville, 1998). Prioritizing requirements “assists project managers with resolving conflicts, plan for staged deliveries, and make necessary trade-off decision” (Aurum and Wohlin, 2005).

During analysis, models are created from different perspectives to develop an understanding of the system, as well as checking for necessity, completeness, consistency and feasibility. A system model abstracts the system leaving out the unnecessary details. Models enable to filter out the complexities of the real world not relevant for the time being, so that directed effort can be put towards the most important parts of the system under development (Giaglis, 2001; Kotonya and Sommerville, 1998; Sommerville, 2007). Moreover, visualizing requirements as models helps the customer better understand the requirements (Tavassoli, 2009).

Requirements specification refers to the production of a requirement document which can be systematically reviewed, evaluated, and approved (Bourque and Dupuis, 2004). Once the requirements are agreed upon between the stakeholders and the development team, they are specified in a document, popularly known as Software Requirements Specification (SRS) document. This is an official statement of what is required of the system developers. Its purpose is to be an authoritative statement of ‘what' the software is to do. As far as possible, the document shall not address the design and implementations issues, and should be detailed enough to allow the design of the software without user involvement. In general, the size and content of the SRS document should reflect the size and complexity of the software product.

The many sections in the SRS document should detail various aspects of the software system to be developed, mainly: functional requirements, non-functional requirements, design constraints and interface specifications (Kotonya and Sommerville, 1998; Sommerville, 2007). IEEE (1998) has defined a standard known as “IEEE Std 830-1998” which provides guidelines for documenting software requirements specification.

The requirements document along with the models can be and should be managed using requirements management tools such as Telelogic DOORS or IBM Rational RequisitePro.

The requirements validation process ensures that the software engineer has understood the requirements. It is also important to verify that a requirements document conforms to company standards, and that it is understandable, consistent, and complete (Bourque and Dupuis, 2004). The process attempts to identify the errors in the SRS document before it is used as a basis for further system development. In other words, requirement validation is concerned with demonstrating that the requirements define the system that the customer really wants. Prototyping, reviews, inspections, and test case generation are the most commonly used requirements validation techniques.

By engineering systems, we mean consumer or capital products and systems ranging from simple to quite complex ones. Especially in modern energy applications, these may also incorporate many kinds of software, thus forming “hybrid systems” that contain material and immaterial parts. The following discussion will be limited to systems consisting of hardware only.

In engineering systems design, RD is usually taken into account, as stated in most engineering design textbooks. For instance, Cross (1989) suggests the use of a goal tree to vaguely collect the initial requirements. The requirements are further refined as the problem understanding of the customer and engineers increases. Pahl and Bietz (1996) suggest a sequential process model in which the engineer has to extract the requirements from the customer’s wishes. They also recognize that customers are often not able to express their requirements appropriately; however, methods for eliciting these requirements are not suggested. Ulrich and Eppinger (2008) collect the requirements in hierarchical weighted lists. They also state that it is important to reveal implicit customer needs, and that a common product understanding between customer and engineer is necessary.

In their comprehensive review, Jiao and Chen (2006) state that RD usually encompasses only the three activities of elicitation, analysis and specification. During Elicitation, approaches used can be classified into:

Psychology-based approaches: where techniques such as Kansei engineering; Kawakita Jiro method, affinity diagrams, and laddering can be employed.

Methods and tools from the field of knowledge acquisition: where techniques employed can be:

(a) “Contrived” (not-heavily dependent on natural language dialogue, but good at reducing systematic bias, eliciting implicit knowledge, representing declarative and procedural knowledge): e.g. sorting, laddering, repertory grids.

(b) “Non-contrived” (traditional) techniques: e.g. surveys, observations, ethnography, self-reports, interviews.

AI-based approaches: where fuzzy systems, regression analysis, and expert systems have been developed for eliciting customer requirements more accurately and objectively. Also, integrated approaches by combining picture sorts and laddering, fuzzy evaluation and neural network techniques.

Knowledge recovery: from historical data.

Case studies of elicitation in practice are available in the literature. This is described by Mathelin et al. (2005) for the automotive domain, and by Ward et al. (2003) and Agouridas et al. (2006) for medical devices.

Activities in the Analysis phase consist of:

Understanding market and customer needs.

Customer preference.

Prioritization: By assigning different importance weights for customer requirements. This affects the target values to be set for the engineering characteristics. Existing techniques are:

(a) AHP (Analytic hierarchy process)

(b) Fuzzy AHP

(c) Using supervised learning with a radial basis function (RBF) neural network

(d) Applying conjoint analysis to prioritize customer requirements through pairwise comparisons

Classification: This helps guiding the designer in compiling, organizing, and analyzing product design issues. Existing techniques are:

(a) Affinity diagrams

(b) Ontology for representing requirements that supports a generic requirement process. Ontology defines parts, features, requirements and constraints

(c) Taxonomic approach (developing a set of taxonomies to assist in gathering, storing, using and reusing requirements)

Specification is concerned with the creation of a structurally concrete and precise specification of product requirements based on functional knowledge that has been elicited from key stakeholders. Common techniques are:

Requirement transformation: e.g. Customer optimization route and evaluation (CORE) model; methodology of organizing specifications in engineering (MOOSE)

QFD. To translate customer requirements to technical design requirements

Fuzzy QFD: To enhance handling of ambiguous requirement information and evaluating inputs. Subjective crisp variables are expressed as fuzzy numbers

Prioritization of design requirements. Importance rating among engineering characteristics in the QFD; a linear programming model for the prioritization of design requirements in the QFD planning process; employing a fuzzy outranking approach to prioritize the design requirements in the QFD

Targets of design requirements: (usually defined by design teams subjectively and empirically) Using a fuzzy set theoretic approach to determine optimum target values for the engineering characteristics in QFD with consideration of the relevant constraints; using fuzzy regression and fuzzy optimization.

Therefore, as the RD phases proceed, the informally expressed needs of stakeholders are explored, developed and expanded into a more complete and formal document, variously known as the product description, technical specification, or Product Design Specification (PDS), that is understood and agreed upon by all stakeholders, and from which a design solution can be proposed.

RD in software engineering is highly elaborated and many methods and process models are known. Software engineering sees RD as a continuous activity that is performed throughout the entire development process, while product/ systems engineering considers RD as a phase at the beginning of the project.

The specification of requirements in software engineering results from not only the transformation of customer requirements from those end-users, but also considerations of many engineering concerns. This is consistent with the principle of viewpoint-oriented software requirement engineering, where multiple viewpoints encapsulate different types of requirement models natural to different stakeholders.

RM involves two main tasks, namely: (a) requirements traceability, performed once the specifications have been documented, in order to determine the links between various requirements; and (b) change impact analysis, conducted at any stage of the design process, once a change of any kind has been proposed, in order to determine the feasibility, implications, cost, etc, of such a change, and finally deciding on its approval, as illustrated in Figure 3.

Changes in requirements are always expected. Indeed, they are the norm and not the exception, since most complex projects involve interdisciplinary system scenarios. In these cases, the stakeholders needs are usually not fully identified, and hence the requirements and the specifications are loosely-defined. Therefore, those initial requirements can be expected to change for a variety of reasons, e.g. altered market needs, safety concerns, problem corrections, new constraints, introduction of new technologies, uncertainty of resources, cost considerations, legislation changes, etc. On the other hand, in such systems, components are usually highly interconnected; a change to one requirement in one component can propagate through the system and cause other changes in other components and parts. The change can also spread to other products (e.g. other family members) due to common platforms, other processes (e.g. manufacturing), and other businesses (e.g. suppliers, partners, etc.) (Jarratt et al., 2011). Hence, the need of fullscale traceability between all system players.

In complex systems, it is important to identify and stabilize the requirements as early as possible in the process. Otherwise, inevitable changes will cause disruption of the product development schedule, increase of costs, and failure to meet the expected system quality. Table 1 shows the relative costs of fixing requirements defects in different phases of a project. Whatever it may cost to do things right in the requirements phase, it may be 3 to 1000 times more costly to fix later.

Similarly, Table 2 shows that return on investment (ROI) from practicing good requirements management is substantial, in terms of its results and benefits.

Finally, a European study by Blackburn et al. (1996) showed that teams that developed products more quickly were found to have devoted more of their schedule and effort to requirements than did slower teams (Table 3).

With respect to managing requirements change in software development, the requirements can be broadly categorized into volatile (requirements that are likely to change), and non-volatile requirements (stable ones) (Sommerville, 2007; De Lucia et al., 2008). As a proactive way to manage changing requirements, the volatile requirements are sometime further categorized. Categorizing requirements helps in change management as the reason and justification for change is better understood and proper attention can be given to different categories of non-volatile requirements (Sommerville, 2007; Harker et al., 1993). Additionally, if a change can be categorized, we can understand its impact and how much control we have on this change (McGee and Greer, 2009). One of the popular categories of changing requirements is that proposed by Harker et al. (1993). Sometimes the changes are categorized from the developer’s perspective too (Nurmuliani et al., 2004). During categorization of requirements, it is also helpful to assess the probability of the change to that requirement (De Lucia et al., 2008). A simplified view of the change management process is shown in Figure 4.

A requirements change normally begins as a request, either formal or informal. Informal change requests need to be checked and controlled as far as possible as it leads to many problems due to inadequate allocation of schedule and manpower to manage those changes. A formal change request needs to be documented from the beginning. A change request has many attributes apart from the requested change itself. Among the important attributes for a change request are type of change < add, delete and modify> (Strens and Sugden, 1996; McGee and Greer, 2009), the importance of change (O’ Neal and Carver, 2001), the reasons and justification and the source of change (Nurmuliani et al., 2004; McGee and Greer, 2009). It may not be possible to collect and document all the attributes for a given change request but the more the information available on these attributes, the easier it is to handle them.

Once the change request is received, the next important activity is to assess the impact of implementing this change. This is popularly known as impact analysis. Conducting impact analysis helps answer many questions related to the impact of implementing this change. Among the important aspects are, when in development cycle the change needs to be implemented (Ramzan and Ikram, 2006; Imtiaz et al., 2008; Strens and Sugden, 1996), what artifacts are impacted by this change (Ramzan and Ikram, 2006; De Lucia et al., 2008; O’Neal and Carver, 2001; Imtiaz et al., 2008), the degree of change (De Lucia et al., 2008; O’ Neal and Carver, 2001; Strens and Sugden, 1996) and who among the stakeholders are impacted by the change (Ramzan and Ikram, 2005; O’ Neal and Carver, 2001). Figure 5 shows the impact of change affecting different phases and artifacts.

One of the main techniques to do the impact analysis is the use of traceability matrix. A traceability matrix represents the dependency relationships between different requirements and also across different artifacts. This dependency relationship can be of different types like ‘dependent,’ ‘ related.’ There are different types of traceability matrix depending on the level of details it works on, the type of information it stores, etc. (Ibrahim et al., 2005; O’Neal and Carver, 2001). An example of a simple traceability matrix is shown in Figure 6. A common categorization of traceability matrix is vertical versus horizontal traceability matrix. A vertical traceability matrix includes dependency relationship between artifacts and entities from different phase of development whereas a horizontal traceability matrix includes relationship between artifacts and entities within a development phase.

To come up with the traceability matrix for a project is a major task. The core of this issue is to build the dependency relationship between different entities and artifacts. For relatively small projects it may be feasible to build these relationships manually, but for large complex systems, we need some level of automation (Ibrahim et al., 2005). There are various techniques employed for automation ranging from heuristics, information retrieval, data mining, domain knowledge and this is a hot area in research (Imtiaz et al., 2008). Moreover, the relationship between artifacts and entities can be direct, where an artifact or an entity is directly affected by the change, or indirect, where an artifact or an entity may be affected indirectly due to its relationship to other artifacts and entities that are affected directly by the proposed change (Strens and Sugden, 1996). This phenomenon is sometimes termed as “ripple effect”, and the chain of this ripple effect may not be limited to only one level but to a number of levels with different degree of effect (Bohner, 2002, De Lucia et al., 2008, Ramzan and Ikram, 2005).

Once the impact analysis is conducted using the traceability matrix, a candidate impact set is obtained which includes all the artifacts and entities affected directly or indirectly by the proposed change. It shall be kept in mind that this impact set is not always accurate in the sense that it may not be able to include all the possible artifacts and entities, and accordingly some of them might be left out (termed as false negatives). Additionally, the impact set may include some artifacts and entities which may in reality not be affected by this change (termed as false positives) (Bohner, 2002). The effectiveness of a given technique for impact analysis and traceability matrix is mostly judged considering these false positives and false negatives. Figure 7 shows the process of impact analysis. The impact itself may be measured in terms of degree and probability of impact.

The results of impact analysis is further studied by employing cost benefit analysis which not only considers the technical implications of change but also other aspects like management, administrative, cost/budget and project schedule (Imtiaz et al., 2008). Once the complete analysis is done, a final decision is made on whether to implement this change request or to put the change request on hold. It is important that all the major stakeholders participate in this process and be a part of the final decision.

It is also recommended that there be a clear process and change control body who takes care of the entire change management process instead of change creeping in from anywhere with no proper control on them. This may adversely affect the schedule, cost, and the final quality of the software product. The concept of having an independent change control board is very effective and popular in this respect and is practiced widespread (Leffingwell and Widrig, 2003). There are many requirements change management process proposed in literature and a good comparison on many of them is available in (Ramzan and Ikram, 2005). The process of change management involving change control board is shown in Figure 8. The change control board acts like a firewall by controlling the incoming change and preventing the change creeping in through informal change requests.

General engineering changes during a system’ s lifecycle have been studied intensively in the last decade. A comprehensive review has been reported recently by Jarratt et al. (2011). The subject is still under continuous development, hence no complete books have been devoted to the topic. Results have been published mainly in journal or conference papers and a few book chapters. The change process follows the plan given previously in Figure 3, with many iterations and break/ stage-gate points.

As seen in Figure 9, the sources of changes throughout the design process are numerous, and can be emergent (i.e. arising from the properties of the system itself), or initiated (for improvements, enhancements, or adaptations of the system). The initiation source can be internal (operational experience, manufacture/ assembly, production, build), or external (customer, supplier, contractual), with changes in customer requirements playing a substantial role (Table 4).

Eckert et al. (2004) have identified two types of change propagation: (a) Ending ones, consisting of small ripples of change, which are brought to a conclusion within an expected time frame, and (b) Unending ones, consisting of avalanches of change, typical of “a snowball effect,” which occur when a major change initiates several other major changes, and all of these cannot be brought to a satisfactory conclusion.

With innovative systems, changes are much more likely to occur since everything is fuzzy, particularly requirements, at the front end. This is particularly so in hybrid systems governed by both technology push and market pull, as in many emergent energy systems. In theses cases, the best strategy is to isolate the innovation process within R&D laboratories, where “organized chaos” could be controlled and maintained, until new systems (ideas, materials, processes, etc.) are fully developed and successfully tested.

As noted by Jarratt et al. (2011), changes during the design process result in "information deficiencies" for other development teams, whose decisions are then made about the system without up-to-date data (Fricke et al., 2000; Rouibah and Caskey, 2003). In order to remedy this situation, and provide help in decision-making, and the overall engineering change process, engineers need well-designed tools for their support. Such tools should help perform many important tasks, namely: track requirements status; communicate with stakeholders; store requirements attributes; manage versions and changes; facilitate impact analysis; control access; reuse requirements. Some of the academic support tools reported in the literature have been discussed in detail by Jarratt et al. (2011). A few of these will be highlighted here.

Keller et al. (2005, 2007, 2008) developed the Change Prediction Method (CPM) tool, which is a software program for predicting change propagation, by analyzing indirect changes and calculating the combined risk that a change to one component will affect others. The CPM tool makes use of Design Structure Matrices (DSMs) to provide a simple, compact, and visual representation of the probability that a change will propagate from one component to others. The tool can be used in all life-stages of a system, such as in the conceptual design, detail design, and operational life-stages.

In parallel, Koh and Clarkson (2009) presented a modeling method that aims to manage the effects of change propagation, and applied the method to the design of a jet engine fan. The method uses a matrix-based approach to model the dependencies between the solution alternatives, the potential change propagation brought about by the solutions, the affected product attributes, and the resources needed to carry out the change work. The method allows engineers to trace critical change propagation paths and manage them, and hence appears to be suitable for assessing solution alternatives during preliminary design and exploring the design space in the right direction.

Lemmens et al. (2007) analyzed the impact of change from different points of view e.g. requirements, physical or functional product architecture, design processes or activities, organization, with the aim of facilitating decision- making by improving the visibility and shared understanding of the interdependencies that exist within and between such viewpoints. Change Propagation Analysis (CPA) algorithms were proposed and implemented in a prototype software environment to allow the modeling and visualization of multiple dependencies across multiple information domains, including lifecycle considerations.

Tracking changes can always give an engineer valuable experience in designing future products. However, this approach is “ reactive” and only addresses the problem of changing requirements after they have occurred and it is too late to adjust the current design. Designing systems should be “ proactive.” Designing with “ changing requirements in mind” can be especially effective when a customer has only loosely identified requirements or when requirements are not fully known. A few approaches have been proposed in that direction.

Qureshi et al. (2006) defined “ product flexibility” as the adaptability of a system in response to changing factors. Since flexible products were realized with ad hoc methods that rely on the experience and intuition of the designer, they presented a set of formal principles for guiding the design of flexible products. These principles were derived from the results of an empirical study of the United States patent repository. They also validated the effectiveness of these principles using a Change Modes and Effects Analysis (CMEA) tool.

The Design For Variety (DFV) method uses product platform architecture to provide a structured approach to reduce the amount of redesign effort for future generations of a product. For large projects, system architecture can be used to break down the design into smaller subsystems at each level of the design hierarchy (Hintersteiner, 2000). The DFV has the advantage of being a simple and inexpensive technique to determine potential design changes. The methodology makes use of standardization and modularization techniques to reduce future design costs and efforts (Martin and Ishii, 2002). The design for variety method develops two indices to measure a product’s architecture. The first, called the Generational Variety Index (GVI), is an indicator of the amount of redesign effort required for future iterations of a product. The other is called the Coupling Index (CI), and it is used to gauge the extent of coupling among the different components in a product. DFV can be used to help reduce the impact of variety on the lifecycle costs (Martin and Ishii, 2002).

Peterson et al. (2007) identified six product development strategies to cope with changing requirements and specifications. These strategies were tested while developing working product prototypes for their project. These six recommendations are:

Establish and foster open communication between designers and customers.

Develop and explicitly write down a complete list of design requirements..

Analyze the list of requirements to identify which requirements are likely to change and which are stable.

Predict future market/ customer needs and requirement changes.

Use an iterative approach. Quick turnover of designs and prototypes provides a method for testing requirements and discovering unanticipated ones.

Build flexibility into the design by selecting product architectures that tolerate changing requirements. This can be achieved by over-designing components that are likely to change to meet future needs.

Freezing requirements is one way designers try to deal with changing requirements. One goal of a freeze is to reduce the likelihood of design changes. The major benefits from using design freezes are the ability to structure the design process and to control design changes (Eger et al., 2005). A design freeze marks the end of a development stage where requirements become fixed before the design can continue (Eger et al., 2005). Early design freezes have the benefit of pushing any design changes to future product generations. This can be constructive in an iterative design process. Early design freezes can also force a design before it is beneficial to do so. When the exact requirements are uncertain, it may be advantageous to postpone a design freeze. Some changes due to safety concerns, problem corrections, or altered customer requests will still have to be carried out regardless of whether a component is frozen. Changes after a freeze are likely to be more costly, and the cost will continue to increase the later the change is implemented (Eger et al., 2005). Many designers feel it is best to keep parts flexible where changes are anticipated.

Information about design freezes is especially important when working in a team. Recognizing the dependencies between parts and acknowledging which parts may be frozen can avoid inadvertent changes to the overall design.

Some of the methods developed for software engineering to assess the impact of a design change can be applied to engineering systems with some adaptation. As noted by Peterson et al. (2007), the difficulty lies in that software design is only concerned with the transmission of information, while engineering systems design must also deal with material and energy transfer.

A couple of models used in software engineering consider changes in evolutionary software development (Schach and Tomer, 2000; Rajlich, 2000). However these models are not appropriate for engineering systems design where component interfaces are not as explicit and involve more than just information transmission. Generally, these programs only identify the immediate implications of change within the immediate sub system and are not capable of exploring the consequences of change propagation through complex systems with different mechanical interactions (Keller et al., 2005).

An important concept that should be carried over from software to engineering systems is the adoption of a socio-technical approach which contends that communication problems can be reduced if all stakeholders are involved in all phases of the design process.

The idea of guessing future changes in software (Future Analysis) can also be applied to engineering systems design. A robust design is one that can cope with alternative futures (Land, 1982). In order to build robust systems the designer must attempt to consider all possible alternative futures. The outcome of the analysis of the system for future changes is a list of system features which are likely to be affected. Building flexibility into a system can be beneficial but is often expensive so it is important to determine where best to build flexibility into the system (Land, 1982). The target lifespan will determine how much flexibility the system should have to meet that target.

For both software and engineering systems, commercial software tools are available to handle RM. Some of these tools are compared in Table 5 and Table 6.

Since requirements development and management are among the most important activities in any software or engineering system project, efforts towards improving these two tasks can always increase and accelerate the ROI. According to the “garbage in, garbage out” rule: If the requirements are not “good” and “properly managed,” all subsequent efforts will only help design, make, and market the wrong unneeded product faster.

The analysis of the mentioned literature revealed that RE in product engineering is mostly restricted to the early phases of the development process. During the late phase, RE does not seem to play a substantial role. Most of these approaches state that the customer plays a central role during the entire development process. The type and degree of customer integration into the development process varies. The integration of the customer into the process of requirements elicitation is emphasized, but not in later phases.

RE is a well-established discipline in software development. This is clear from the many textbooks that have appeared on the subject and the many courses in curricula of various software engineering programs. In contrast, there are no books dedicated to this subject for designing engineering systems. A special journal issue of Research in Engineering Design on “Engineering Change” is forthcoming in 2011 (Eckert et al., 2010).

Following is Table 7 compares the degree of achievement of various RD and RM tasks in software and in engineering systems.

Both software and engineering systems lack the coverage of RD and RN in complex innovative and/ or hybrid applications.

As seen also in the Table, RD and RM are applied in a structured way in software systems, whereas a few areas are still under-developed for engineering systems; further research in that direction is needed.