China
Africa
Explore chapters and articles related to this topic
Tool Support for Requirements Engineering
Published in Phillip A. Laplante, Mohamad H. Kassab, Requirements Engineering for Software and Systems, 2022
Phillip A. Laplante, Mohamad H. Kassab
Requirements traceability is a subdiscipline of requirements management, and it is one of the main capabilities to look for in requirement tools. Requirements traceability is concerned with the relationships between requirements, their sources, and numerous other artifacts. Different kinds of traceability can be established: Source Traceability: This provides links requirements to stakeholders who proposed these requirementsRequirements-Linkage Traceability: This provides links between dependent requirements.Requirements-Design Traceability: This provides links from the requirements to the design.Requirements-Source Code Traceability: This provides links from the requirements to the code.Requirement-Test Cases Traceability: This provides links from the requirements to the test cases.
Systems Engineering and Weapon Systems Acquisition Strategy of the U.S. Department of Defense and National Security
Published in Anna M. Doro-on, Handbook of Systems Engineering and Risk Management in Control Systems, Communication, Space Technology, Missile, Security and Defense Operations, 2023
The systems engineer develops and manages the requirements traceability matrix (RTM) that documents all requirements; the template is shown in Table 2.13C. The purpose of the RTM is to determine where requirements, including the interface requirements agreements, are satisfied by the design and the design specifications are satisfied by the code (DAU 2012b). Requirements traceability refers to the ability to follow the life of a requirement, both forward and backward (i.e., from its origins, through its development and specification), to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases, and is used to capture the relationships between requirements, design, test, and implementation of a system (DAU 2012). The RTM can also expose requirements that have not been satisfied or tested and expose design specifications that have not been satisfied with code (DAU 2012b). Viewing the RTM from the opposite perspective, it can expose design and test scripts for which no requirement has been written and code which has no corresponding design specifications (DAU 2012b). The lack of requirements may mean that the design or test scripts have become obsolete or, from the opposite perspective, that the missing requirements are valid but have never been documented (DAU 2012b). The PM should often provide up-to-date information to stakeholders and leadership regarding status of cost, schedule, and performance impacts generated from requirements derivations or expansion. With the assistance of PM and systems engineer, all stakeholders, decision makers, and leadership must well-informed and entirely understand the impacts of potential requirements changes at the system or element level prior to approval of any changes for adding them into the design.
Software Configuration Management
Published in Leanna Rierson, Developing Safety-Critical Software, 2017
Traceability analysis—identifies the requirements, design elements, code, and test cases and procedures that may be either directly or indirectly affected by the change. Forward traceability of changes identifies design components affected by the change. Backward traceability helps determine other design features and requirements that may be inadvertently affected by the change. Overall, the requirements traceability helps determine the impact of change on the software project. It is important to identify both changed and impacted software and data.
Understanding Failed Software Projects through Forensic Analysis
Published in Journal of Computer Information Systems, 2022
William H. Money, Stephen H. Kaisler, Stephen J. Cohen
Fretty15 article begins to address the forensic analysis advocated in this paper by citing the need for a solid measurement system and a comprehensive risk-tracking mechanism to help unearth the root cause(s) of a failing project’s problem. This could realistically involve identifying stakeholders, needs, attributes of the needs, and performance measures. Fretty’s citation of a survey of the top 10 reasons why IT projects fail according to iRise (Software services company in El Segundo, Calif., USA., unpublished) helps to that focus failed project analysis on two key failure factors – the team and the requirements. The survey produced a broad list of reasons for reasons for project failures attributable to these categories. It identifies inconsistent team skill sets; extensive (too many) requirements; an overwhelmed requirements management process; ambiguous requirements; unrealistic requirements that cannot be implemented; a focus on simple requirements (not difficult ones); requirements that are clear to the team but not to stakeholders; a belief that requirements review iterations are too time-consuming; stakeholders who don’t mean what they say; and too difficult to manage requirements traceability. Another surveys by Discenza and Forman16 used a survey to identify the common causes of project to suggest mitigation approaches, damage control strategies, and recovery techniques.
Continuous Integration, In-Code Documentation, and Automation for Nuclear Quality Assurance Conformance
Published in Nuclear Technology, 2021
Andrew E. Slaughter, Cody J. Permann, Jason M. Miller, Brian K. Alger, Stephen R. Novascone
Using these three items, which exist within all the test specifications of MOOSE, a software quality extension “sqa” was created within MooseDocs to automatically generate a complete list of the system requirements, requirements traceability matrix, and the requirements cross reference.7 A portion of the traceability matrix for MOOSE is shown in Fig. 8. Most importantly, these aspects of the NQA-1 documentation are always up to date for every change in the repository. The reader is encouraged to visit the MOOSE websiteehttps://mooseframework.org. to explore these complete documents in more detail. The traceability generated by MooseDocs includes testing information from all combinations of operating system and support software that were executed; most tests are executed 60 or more times before integrated into the master branch.