China
Africa
Explore chapters and articles related to this topic
Microcontroller Software
Published in Syed R. Rizvi, Microcontroller Programming, 2016
Since in this book we will be dealing with programs that are relatively smaller in size, one person will be performing all the just listed tasks. However, in a project of relatively larger size involving numerous personnel, this process is often referred to as a software development process. Perhaps the most crucial task in creating a software product is extracting the requirements. This is called requirements analysis. Customers (end users of embedded system applications) typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Customer and product requirements are enumerated in a bidirectional traceability matrix. Whereas customer requirements define the problem to be solved, product requirements define the sensible features of the solution. A bidirectional traceability matrix maps requirement, design elements, code snippets, and test steps. Good traceability practices allow for bidirectional traceability, meaning that the traceability chains can be traced in both the forward and backwards direction as illustrated in Figure 4.6. Forward traceability looks at tracing the requirements sources to their resulting product requirements to ensure the completeness of the product requirement specification. Forward traceability is also a mechanism for tracing each unique product requirement forward into the design that implements that requirement, the code that implements that design and the tests that verify that requirement and so on. The goal is to ensure that each requirement is implemented in the product and that each requirement is thoroughly tested. The backwards traceability looks at tracing each unique work product (e.g., design element, code segment or unit, test procedures, etc.) back to its corresponding requirement. Backward traceability can verify that the requirements have been kept current with the design, code, and test. It is a mechanism that traces each requirement back to its source.
Product realization
Published in Itay Abuhav, ISO 13485:2016 A Complete Guide to Quality Management in the Medical Device Industry, 2018
In practice, you may implement a requirements traceability matrix (RTM) as a method for traceability of the specifications (the inputs) to the final results (the outputs). A requirements traceability matrix is a method that links two aspects of design and development (the inputs—the specification—and the results, the outputs) and enables the verification that outputs are achieving the design and development specifications (the inputs). The advantages of this method are that all inputs and outputs are controlled under the same matrix, and it allows effective management of location and status and of each relevant document. The columns of the matrix may be: Unique identification of each specification or inputRequirement type and descriptionNeeded resources (personnel, equipment, or work environment)Reference to relevant documentationLink to the design and development task or activityTrace to design specificationDescription of the expected results (the outputs) or reference to themList of required validations and tests and their relevant criteria (if applicable)Records and evidence as results of the tests and validationsStatus of the design and development taskFinal evaluation of the results
Towards a Systematic Requirement-Based Approach to Build a Neutronics Study Platform
Published in Nuclear Science and Engineering, 2023
Alberto Previti, Alberto Brighenti, Damien Raynaud, Barbara Vezzoni
In order to follow the specification tree, the capture of relevant information shall start from the relevant experience of all the actors involved in the calculation platform and shall be systematically traced down to the use cases and requirements specification database. Both the described top/down propagation and the requirement allocation should be monitored. In particular, the propagation to lower levels depicted with the relation “is satisfied by” between parent and children requirements allows one to generate a traceability matrix, which is a tool to verify compliance. The traceability matrix shows in a compact way the links of the requirements tree, and it should be established to appropriately keep up to date each level of the specification, in particular, when a given feedback or consideration in a lower level triggers a modification to upper levels. In this way, they permit the following of the potential iterations of the V-model caused by the update of use cases or system requirements triggered by the later analysis during the development or test phases.