Showing papers on "Software requirements specification published in 1994"
TL;DR: This work deploys multiple ViewPoints that hold partial requirements specifications, described and developed using different representation schemes and development strategies, and proposes a general model for ViewPoint interaction and integration.
Abstract: Composite systems are generally comprised of heterogeneous components whose specifications are developed by many development participants. The requirements of such systems are invariably elicited from multiple perspectives that overlap, complement, and contradict each other. Furthermore, these requirements are generally developed and specified using multiple methods and notations, respectively. It is therefore necessary to express and check the relationships between the resultant specification fragments. We deploy multiple ViewPoints that hold partial requirements specifications, described and developed using different representation schemes and development strategies. We discuss the notion of inter-ViewPoint communication in the context of this ViewPoints framework, and propose a general model for ViewPoint interaction and integration. We elaborate on some of the requirements for expressing and enacting inter-ViewPoint relationships-the vehicles for consistency checking and inconsistency management. Finally, though we use simple fragments of the requirements specification method CORE to illustrate various components of our work, we also outline a number of larger case studies that we have used to validate our framework. Our computer-based ViewPoints support environment, The Viewer, is also briefly described. >
662 citations
TL;DR: An example specification demonstrates the practicality of writing a formal requirements specification for a complex, process-control system; and the feasibility of building a formal model of a system using a specification language that is readable and reviewable by application experts who are not computer scientists or mathematicians.
Abstract: The paper describes an approach to writing requirements specifications for process-control systems, a specification language that supports this approach, and an example application of the approach and the language on an industrial aircraft collision avoidance system (TCAS II). The example specification demonstrates: the practicality of writing a formal requirements specification for a complex, process-control system; and the feasibility of building a formal model of a system using a specification language that is readable and reviewable by application experts who are not computer scientists or mathematicians. Some lessons learned in the process of this work, which are applicable both to forward and reverse engineering, are also presented. >
570 citations
TL;DR: An exploratory study is conducted to investigate the performance of three methodologies in aiding novice systems analysts who were learning to specify information requirements and the structured techniques and JSD were investigated.
Abstract: pccifying information requir~mcnts-dcttr~i”i~g and documenting the requirements for an information system, is arguably the key to developing successful information systems (IS). Since this is the first step in the systems development process, it is clear that not doing it effectively will have significant impact on both the effectiveness and the efficiency of the resultant system. Not getting the correct final system requirements initially is largely responsible for the cost and schedule overruns that are still fairly prevalent in IS development. Specifying information requirements is not only the most important step in developing IS, it is probably also the most difficult. The crucial aspect of the process is to develop a mental model ofthe system (i.e., to determine what the system needs to do) [6]. Once the information requirements ofthe new IS have been specified, the development process consists of successive transformations ofthat initial model until, finally, a computerbased solution to the problem is achieved. Specifying requirements is a complex task that is diff< for systems analysts to address, due to human prohlrrn-solving limitations [5]. Short-term memory is limited in capacity; transfer from short-term to long-term memory requires a relatively long time, approximately 5 to 10 seconds; storage and retrieval mechanisms are fallible. Short-term memory capacity is perhaps the most devastating aspect of these limitations. Classical estimates of short-term memory capacity suggested that problem solvers can effectively handle 7 ? 2 chunks of information [14], but this is an upper limit that may be drastically reduced by interference. To overcome these limitations, human problem solvers resort to various ways of effectively increasing the capacity of short-term memory as well as using external memory devices and/or techniques to support working memory. The aid most commonly used to support working memory in information requirements specification is a systems development methodology and the associated representation technique. By methodology, we mean a systematic approach to the task of systems development (see [Xl). Early methodologies provided guidelines mostly in the form ofa set of standardized activities and standardized forms to be completed; little effort was devoted to handling complexity explicitly. Subsequently, the major thrust ofmethodologies has been the desire to address complexity directly [6, 8, lo]. Despite the significance of information requirements specification to the successful design of systems and the large body of descriptive and conceptual literature on methodologies, there have been surprisingly few empirical studies conducted on the methodologies themselves. In fact, review of the literature revealed only one such study, by Yadav et al. [24], who investigated the effectiveness of data flow diagramming [8] and a variant of the systems analysis and design technique (SALT) [ZO] in specifying information requirements. They report that although data flow diagrams are easier to learn and to UT, neither produced significantly better specifications. Given the importance of methodologies to IS development and the dearth ofempirical evidence regarding their use, we conducted an exploratory study to investigate the performance ol three methodologies in aiding novice systems analysts who were learning to specify information requirements. The methodologies investigated were the structured techniques [6, 8, 251, Jackson System Development USD) [lo], and the object-oriented approach [3]. We investigated the structured techniques and JSD because they arc currently the most widely used struttured analysis methodologies (see Necco et al.) [15]. Since object-oriented approaches to systems development are receiving considerable attention in the software engineering arena and since some firms, such as Arthur Andersen Consulting, are moving toward replacing their current methods with object-oriented methods, it seemed appropriate to investigate the relative merits of an object-oriented approach in a business setting.
232 citations
21 May 1994
TL;DR: Key ideas and research issues that have driven RML and its peers are highlighted, evaluated retrospectively in the context of experience and more recent developments, and significant remaining problems and directions for requirements modeling research are pointed out.
Abstract: Research issues related to requirements modeling are introduced and discussed through a review of the requirements modeling language RML, its peers and its successors from the time it was first proposed at the Sixth International Conference on Software Engineering (ICSE-6) to the present - ten ICSEs later. We note that the central theme of "Capturing More World Knowledge" in the original RML proposal is becoming increasingly important in requirements engineering. The paper highlights key ideas and research issues that have driven RML and its peers, evaluates them retrospectively in the context of experience and more recent developments, and points out significant remaining problems and directions for requirements modeling research. >
204 citations
21 May 1994
TL;DR: A scenario-based detection method, in which each reviewer executes a specific procedure to discover a particular class of defects has a higher defect detection rate than either ad hoc or checklist methods.
Abstract: Software requirements specifications (SRS) are usually validated by inspections, in which several reviewers read all or part of the specification and search for defects. We hypothesize that different methods for conducting these searches may have significantly different rates of success. Using a controlled experiment, we show that a scenario-based detection method, in which each reviewer executes a specific procedure to discover a particular class of defects has a higher defect detection rate than either ad hoc or checklist methods. We describe the design, execution and analysis of the experiment so others may reproduce it and test our results for different kinds of software developments and different populations of software engineers. >
134 citations
18 Apr 1994
TL;DR: This work outlines an extended requirements and information modelling paradigm, based on a number of interrelated meta-models, that reflects the enterprise and its objectives, its non-functional requirements on the system, re-use of existing specification components, and a model for managing and tracking the specification development process.
Abstract: Requirements specification methods and techniques have hitherto mainly been concerned with promoting various representation formalisms for formally describing information systems and discussing their expressive power. However, this approach concentrates only partially on the problem. A major issue is how to bridge the gap between ill-defined problem and application situations, and specification of the formal, precise definition of functional requirements of the information system. We outline an extended requirements and information modelling paradigm, based on a number of interrelated meta-models. These models reflect the enterprise and its objectives, its non-functional requirements on the system, re-use of existing specification components, and a model for managing and tracking the specification development process. >
102 citations
05 Jul 1994
TL;DR: This position paper will elaborate the requirements and outline a strategy for the design and implementation of a composition language for the development of open systems to better support application evolution and flexibility.
Abstract: The key requirement for open systems is that they be flexible, or recomposable. This suggests that they must first of all be composable. Object-oriented techniques help by allowing applications to be viewed as compositions of collaborating objects, but are limited in supporting other kinds of abstractions that may have finer or coarser granularity than objects. A composition language supports the technical requirements of a componentoriented development approach by shifting emphasis from programming and inheritance of classes to specification and composition of components. Objects are viewed as processes, and components are abstractions over the object space. An application is viewed as an explicit composition of software components. By making software architectures explicit and manipulable, we expect to better support application evolution and flexibility. In this position paper we will elaborate our requirements and outline a strategy for the design and implementation of a composition language for the development of open systems.
95 citations
Book•
02 Jan 1994
TL;DR: A Comparative Description of Object-Oriented Specification Languages and an Environment for Formal Specification and Prototyping in Smalltalk.
Abstract: Specification and Analysis Techniques in Object-Oriented Methods. A Comparative Description of Object-Oriented Specification Languages. Object-Oriented Specification Languages in the Software Life Cycle. The UNIX File System: A MooZ Specification. An Object-Z Specification of a Mobile Phone System. Object-Oriented Specification in VDM+ +. Specifying a Concept Recognition System in Z + OOZE with Examples. Refinement in Fresco. SmallVDM: An Environment for Formal Specification and Prototyping in Smalltalk.
87 citations
Patent•
06 Jul 1994TL;DR: In this article, a method of performing software validation testing on large electronic systems applies Usage Concepts specially modelled as Markov chains to forrealize the expected use of the system, to define the system behavior, and to introduce statistical measurements.
Abstract: A method of performing software validation testing on large electronic systems applies Usage Concepts specially modelled as Markov chains to forrealize the expected use of the system, to define the system behavior, and to introduce statistical measurements. The functional requirements of the software system are defined in a Markov chain by identifying a plurality of states through which the software system transitions when performing the functional requirements. Stimuli and responses which cause the software system to transition from one state to another are identified, and the probability of each state transition is calculated. Usage cases beginning at an invocation state and ending at a termination state of the software system are defined and listed in order of descending probability of occurrence in a Usage Profile. The Usage Profile, stimuli, and responses are automatically compiled into an automated test program, and associated test equipment is automatically programmed to generate a set of test cases. The set of test cases are then executed on the software system. The end of the set of test cases is determined, and the method analyzes and reports the software system quality.
81 citations
18 Apr 1994
TL;DR: This work shows how requirements conflict resolution can be assisted through a combination of multi-agent multi-criteria optimization and heuristic resolution generation, and summarizes the use of the tool to rationally reconstruct a library specification.
Abstract: Supporting collaborating requirements engineers as they independently construct a specification is highly desirable. We show how collaborative requirements engineering can be supported using a planner, domain abstractions, and automated decision science techniques. In particular we show how requirements conflict resolution can be assisted through a combination of multi-agent multi-criteria optimization and heuristic resolution generation. We then summarize the use of our tool to rationally reconstruct a library specification. This line of research is significant in that it brings conflict detection and resolution into a requirements engineering framework. This particular work expands the automation found in previous results (W. Robinson, 1993). >
76 citations
TL;DR: An object-oriented codesign specification approach designed to eliminate the bias introduced from using more commonplace software or hardware specification languages is described, to investigate automated partitioning of behavior into hardware and software.
Abstract: Describes an object-oriented codesign specification approach designed to eliminate the bias introduced from using more commonplace software or hardware specification languages. The goal is to investigate automated partitioning of behavior into hardware and software. The design methodology allows gradual, continuous repartitioning of codesign operations during design. For instance, designers might start with an all-software implementation and check the implementation's functionality: they might then refine the implementation over time to a mixed hardware-software implementation. At the system level, the authors use an object-oriented approach to identify the basic objects and associated functions of a system. They divide them into three groups: hardware, software, and codesign . They represent the codesign group's objects and functions using a prototype codesign specification language, Object-Oriented Functional Specifications (OOFS), which lets one describe system state in objects and write object methods as pure functions. Thus, the authors can describe complex systems without biasing the implementation toward hardware or software. >
27 Jun 1994
TL;DR: The results have verified the method's practicality and effectiveness at "building in" correctness during requirements analysis, and demonstrated that the benefits of a rigorous approach can be had without adversely affecting cost or schedule.
Abstract: For safety-critical systems, regulatory and human concerns make assurance of requirements correctness a necessity. Most popular requirements methods rely heavily on expensive after-the-fact verification, validation and correction activities to attain a desired level of correctness. In cooperation with its industrial partners, the Software Productivity Consortium (the Consortium) has developed a rigorous requirements engineering method called CoRE ("Consortium Requirements Engineering"), building upon proven formal and object-oriented methods. As part of Continuous Process Improvement (CPI), Lockheed Aeronautical Systems Company (LASC) has incorporated CoRE into its C-130J aircraft program, to develop avionics system requirements. C-130J is a safety critical application. The results have verified the method's practicality and effectiveness at "building in" correctness during requirements analysis. They have further demonstrated that the benefits of a rigorous approach can be had without adversely affecting cost or schedule. >
Proceedings Article•
01 Aug 1994TL;DR: In this article, the authors describe a bottom-up approach to the design of software agents and present an agent system that addresses the real-world problem of handling the activities involved in scheduling a visitor to a laboratory.
Abstract: We describe a bottom-up approach to the design of software agents. We built and tested an agent system that addresses the real-world problem of handling the activities involved in scheduling a visitor to our laboratory. The system employs both task-specific and user-centered agents, and communicates with users using both email and a graphical interface. This experiment has helped us to identify crucial requirements in the successful deployment of software agents, including issues of reliability, security, and ease of use. The architecture we developed to meet these requirements is flexible and extensible, and is guiding our current research on principles of agent design.
TL;DR: Requirement engineering has a fairly narrow goal - determine a need and define the external behavior of a solution - but the range of research into requirements is enormous.
Abstract: Developers have plenty of reasons to avoid investing in requirements engineering: It is next to impossible to capture user needs completely, and needs are constantly evolving. The gap between software research and practice is no more evident than in the field of requirements engineering. Requirement engineering has a fairly narrow goal - determine a need and define the external behavior of a solution - but the range of research into requirements is enormous. >
04 Jul 1994
TL;DR: The Rigorous Object-Oriented Analysis method provides a systematic development process by proposing a set of rules to be followed during the analysis phase that integrates the static, dynamic and functional properties of a system in contrast to other object-oriented analysis methods.
Abstract: The Rigorous Object-Oriented Analysis (ROOA) method provides a systematic development process by proposing a set of rules to be followed during the analysis phase. ROOA takes a set of informal requirements and an object model and produces a formal object-oriented analysis model that acts as a requirements specification. The resulting formal model integrates the static, dynamic and functional properties of a system in contrast to other object-oriented analysis methods which are informal and produce three separate models that are difficult to integrate and keep consistent. The model is expressed in LOTOS and provides a precise and unambiguous specification of a system's requirements. As the specification obtained is executable, prototyping can be used to check the conformance of the specification against the original requirements and to detect inconsistencies, omissions and ambiguities early in the development process.
18 Apr 1994
TL;DR: Domain abstractions are proposed to aid requirements critiquing as well as specification, thus maximising the payoff from retrieving domain abstractions, and Intelligent, mixed initiative dialogue between the critic and requirements engineer permits requirementscritiquing at the right time and level of abstraction.
Abstract: Reusing domain abstractions representing key domain features has been shown to aid requirement specification, however their role in requirements engineering has not been investigated thoroughly. This paper proposes domain abstractions to aid requirements critiquing as well as specification, thus maximising the payoff from retrieving domain abstractions. The requirements critic is part of a prototype intelligent requirements engineering toolkit being developed as part of the Nature project, ESPRIT basic research action 6353. The critic retrieves domain abstractions to validate requirement specifications for problems including incompleteness, inconsistencies and ambiguities. Intelligent, mixed initiative dialogue between the critic and requirements engineer permits requirements critiquing at the right time and level of abstraction. >
01 Mar 1994
TL;DR: A software estimator that provides three software metrics | execution time, program-memory size and data- memory size for a speciication executing on a given processor is presented.
Abstract: Author(s): Gong, Jie; Gajski, Daniel D.; Narayan, Sanjiv | Abstract: Previous work in software/hardware codesign has addressed issues in system modeling, partitioning, and mixed module simulation and integration. Software estimation, which provides software metrics to assist the software/hardware partitioning, has not been studied. In order to rapidly explore large design space encountered in software/hardware systems, automatic software estimation is indispensable in software/hardware partitioning in which designers or partitioning tools must trade off a hardware with a software implementation for the whole or a part of the system under design. In this report we present a software estimator that provides three software metrics --- execution time, program-memory size and data-memory size for a specific executing on a given processor. Experiments have shown that our estimator has less than 20% estimation errors on different designs spanning from straight line code to code with branches and loops and even to hierarchical specifications. Experiments also show that our estimator is fast and can provide rapid feedback to the designers or partitioning tools to quickly evaluate different design alternatives.
TL;DR: The author examines two widely held beliefs: requirements describe a system's "what", not its "how" and requirements must be represented as abstractions.
Abstract: Requirements engineering is likely to be a major issue in this decade. The author examines two widely held beliefs: requirements describe a system's "what", not its "how". Requirements must be represented as abstractions. >
18 Apr 1994
TL;DR: The role of software architecture (which reflects high-level implementation constraints) in requirements engineering is clarified by providing perspectives on relevant issues.
Abstract: The role of software architecture (which reflects high-level implementation constraints) in requirements engineering is clarified by providing perspectives on relevant issues, including the following: is requirements engineering merely a front end to the software development process that is concerned only with problem definition? Is software architecture an application-specific, high-level design of a system (for example, "an object-oriented system with a specified object hierarchy")? What is the relationship between the problem definition and the solution structure? What is the relationship between the roles of requirements engineer, software architect, and application domain specialist?. >
01 Nov 1994
TL;DR: This paper describes a prototype domain modeling environment used to demonstrate the concepts of reuse of software requirements and software architectures and an integrated set of commercial-off-the-shelf software tools and custom developed software tools.
Abstract: This paper describes a prototype domain modeling environment used to demonstrate the concepts of reuse of software requirements and software architectures. The environment, which is application-domain independent, is used to support the development of domain models and to generate target system specifications from them. The prototype environment consists of an integrated set of commercial-off-the-shelf software tools and custom developed software tools. The concept of reuse is prevalent at several levels of the domain modeling method and prototype environment. The environment is domain-independent thereby supporting the specification of diverse application domain models. The domain modeling method specifies a family of systems rather than a single system; optional features characterize the variations in functional requirements supported by the family, and individual family members are specified by the features they are to support. The knowledge-based approach to target system generation provides the rules for generating target system specifications from the domain model; target system specifications, themselves, may be stored in an object repository for subsequent retrieval and reuse. >
06 Nov 1994
TL;DR: BOR testing is very effective at detecting faults in predicates, and that BOR-based approach has consistently better fault detection performance than branch testing, thorough (but informal) functional testing, simple state-based testing, and random testing.
Abstract: We report the results of three empirical studies of fault detection and stability performance of the predicate-based BOR (Boolean Operator) testing strategy. BOR testing is used to develop test cases based on formal software specification, or based on the implementation code. We evaluated the BOR strategy with respect to some other strategies by using Boolean expressions and actual software. We applied it to software specification cause-effect graphs of a safety-related real-time control system, and to a set of N-version programs. We found that BOR testing is very effective at detecting faults in predicates, and that BOR-based approach has consistently better fault detection performance than branch testing, thorough (but informal) functional testing, simple state-based testing, and random testing. Our results indicate that BOR test selection strategy is practical and effective for detection of faulty predicates and is suitable for generation of safety-sensitive test-cases. >
06 Jun 1994
TL;DR: A meta modelling technique by using a formal specification language Object-Z which is an object oriented version of the Z language which allows us to describe hierarchical structures and the constraints in the methods and the inheritance mechanism enables us to integrate method fragments into a new method.
Abstract: To support customizing and integrating software specification & design methods to a suitable method for designers' problem domain and environment, so-called Computer Aided Method Engineering (CAME), we need a meta model for representing the fragments of methods formally and for composing them into a method. This paper discusses a meta modelling technique by using a formal specification language Object-Z which is an object oriented version of the Z language. The logical expressions of Object-Z allows us to describe hierarchical structures and the constraints in the methods and the inheritance mechanism enables us to integrate method fragments into a new method.
TL;DR: The results of four empirical studies indicate that BOR testing is practical and effective for both specification- and program-based test generation.
Abstract: In this paper, we report the results of four empirical studies for evaluating a predicate-based software testing strategy, called BOR (Boolean operator) testing. The BOR testing strategy focuses on the detection of Boolean operator faults in a predicate, including incorrect AND/OR operators and missing or extra NOT operators. Our empirical studies involved comparisons of BOR testing with several other predicate-based testing strategies, using Boolean expressions, a real-time control system, and a set of N-version programs. For program-based test generation, BOR testing was applied to predicates in a program. For specification-based test generation, BOR testing was applied to cause-effect graphs representing software specification. The results of our studies indicate that BOR testing is practical and effective for both specification- and program-based test generation.
21 Sep 1994
TL;DR: Rapid prototyping can be used to check the conformance of the specification against the requirements and to detect inconsistencies, omissions or ambiguities so that feedback can be given to the requirements capture process.
Abstract: The Rigorous Object-Oriented Analysis (ROOA) method provides a systematic development process which takes a set of informal requirements and produces a formal object-oriented analysis model. The model, which is expressed in LOTOS, integrates the static, dynamic and functional aspects of a problem and acts as a requirements specification. As LOTOS specifications can be executed symbolically, rapid prototyping can be used to check the conformance of the specification against the requirements and to detect inconsistencies, omissions or ambiguities so that feedback can be given to the requirements capture process.
01 Jan 1994
TL;DR: A foundation for modeling, specifying and verifying discrete/continuous hybrid systems and take an integrated approach to the design and analysis of robotic systems and behaviors are established.
Abstract: Robots are generally composed of electromechanical parts with multiple sensors and actuators. The overall behavior of a robot emerges from coordination among its various parts and interaction with its environment. Developing intelligent, reliable, robust and safe robots, or real-time embedded systems, has become a focus of interest in recent years. In this thesis, we establish a foundation for modeling, specifying and verifying discrete/continuous hybrid systems and take an integrated approach to the design and analysis of robotic systems and behaviors. A robotic system in general is a hybrid dynamic system, consisting of continuous, discrete and event-driven components. We develop a semantic model for dynamic systems, that we call Constraint Nets (CN). CN introduces an abstraction and a unitary framework to model discrete/continuous hybrid systems. CN provides aggregation operators to model a complex system hierarchically. CN supports multiple levels of abstraction, based on abstract algebra and topology, to model and analyze a system at different levels of detail. CN, because of its rigorous foundation, can be used to define programming semantics of real-time languages for control systems. While modeling focuses on the underlying structure of a system --- the organization and coordination of its components --- requirements specification imposes global constraints on a system''s behavior, and behavior verification ensures the correctness of the behavior with respect to its requirements specification. We develop a timed linear temporal logic and timed $\forall$-automata to specify timed as well as sequential behaviors. We develop a formal verification method for timed $\forall$-automata specification, by combining a generalized model checking technique for automata with a generalized stability analysis method for dynamic systems. A good design methodology can simplify the verification of a robotic system. We develop a systematic approach to control synthesis from requirements specification, by exploring a relation between constraint satisfaction and dynamic systems using constraint methods. With this approach, control synthesis and behavior verification are coupled through requirements specification. To model, synthesize, simulate, and understand various robotic systems we have studied in this research, we develop a visual programming and simulation environment that we call ALERT: A Laboratory for Embedded Real-Time systems.
Journal Article•
16 May 1994
TL;DR: The article surveys formal specification techniques, but, as it is difficult (and probably meaningless) to speak of such techniques independently from the development process, some formal development methods are discussed, as well as the impact of formal specifications on the development activities.
Abstract: Formal approaches to software specification and development have been a topic of active research for a long time. There now exists an important corpus of knowledge and results in this domain. There is more and more interest in the industrial applications of these techniques, even if it is generally observed that transfer is difficult in this area. The article surveys formal specification techniques, but, as it is difficult (and probably meaningless) to speak of such techniques independently from the development process, some formal development methods are discussed, as well as the impact of formal specifications on the development activities. >
Proceedings Article•
01 Dec 1994
TL;DR: Results of an investigation into the effectiveness of formal methods as an aid to the requirements analysis of critical, system-level fault-protection software on a spacecraft currently under development indicate that formal specification and analysis can enhance the accuracy of the requirements and add assurance prior to design development in this domain.
Abstract: Formal specification and analysis of requirements continues to gain support as a method for producing more reliable software. However, the introduction of formal methods to a large software project is difficult, due in part to the unfamiliarity of the specification languages and the lack of graphics. This paper reports results of an investigation into the effectiveness of formal methods as an aid to the requirements analysis of critical, system-level fault-protection software on a spacecraft currently under development. Our experience indicates that formal specification and analysis can enhance the accuracy of the requirements and add assurance prior to design development in this domain. The work described here is part of a larger, NASA-funded research project whose purpose is to use formal-methods techniques to improve the quality of software in space applications. The demonstration project described here is part of the effort to evaluate experimentally the effectiveness of supplementing traditional engineering approaches to requirements specification with the more rigorous specification and analysis available with formal methods.
TL;DR: The requirement traceability procedure described in the paper is a systematic method to assist 5ESS Switch scientists and engineers to achieve the goal of ensuring the feature requirements requested by customers, external and internal, are developed correctly.
Abstract: The waterfall-based software development methodology usually requires significant efforts and lengthy intervals to develop, review, inspect, and test very large and complex real-time software systems. Although the methodology itself is stable and mature, the quality of software products still largely depends on development efforts expended in testing, which is usually very costly and time consuming. The author describes the implementation of an integrated approach of software development, review, inspection, and testing based on well-identified software requirements. Due to the huge size and the complex feature interactions of the 5ESS Switch software, the process of review, inspection, and testing has been very important to the project. To enhance the quality of the products, it is necessary to ensure the feature requirements requested by customers, external and internal, are developed correctly. The requirement traceability procedure described in the paper is a systematic method to assist 5ESS Switch scientists and engineers to achieve the goal. The results of the implementation of the requirement traceability procedure and its RADIX tool are significant. >