China
Africa
Explore chapters and articles related to this topic
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 following sections provide details of the requirements analysis process (RAP) and its activities. Requirements analysis, also known as requirements engineering, is the approach of delineating or completing user specifications and feasible expectations for proposed, new, or upgraded systems. It is the second step in the SE technical process as depicted in Figure 2.2. During the system design development, the requirements analysis also evolves to project management, resource allocation, and derivation of requirements up to the base level of system elements, of which design is represented. There are two vital baselined technical requirements: logical models and derived technical requirements. A logical model makes up the system’s functional architecture that defines and helps in understanding the relationships among the functions, behaviors, data flows, attributes, services, and states and modes of the technical requirements (DAU 2017b). The technical requirements are formed from logical model(s) analysis and then allocated to system model elements, which are used to verify the physical design solution and are an input to the RAP (DAU 2017b).
On Verification and Validation in Engineering
Published in Diane P. Michelfelder, Neelke Doorn, The Routledge Handbook of the Philosophy of Engineering, 2020
Francien Dechesne, Tijn Borghuis
Analytical evaluation methods are distinct from empirical evaluation methods, which perform observations or measurements to compare results with expectations. Rather than on a physical artifact, analytical methods operate on formalized representations of (parts of) the system, and they are aimed at testing for overall logical system conditions such as consistency, completeness and satisfiability of requirements. Analysis also plays an important role in “requirements engineering”: requirements analysis is a verification of the system requirements from a system-designer perspective, checking them for adequacy, redundancy and completeness (ISO/IEC/IEEE 29148, 2018).
Analytical Test Planning for Defense Acquisitions
Published in Natalie M. Scala, James P. Howard, Handbook of Military and Defense Operations Research, 2020
In order to accomplish low-level test designs that culminate in top-level operational testing, a mission systems engineering V-model decomposition, as seen in Figure 11.3, is usually required. This process begins in the upper left with the engineering requirements for the mission success of the system. Requirements analysis encompasses the tasks that determine the needs or conditions that the new system must meet and outputs the operational, functional, and physical systems engineering views of the system. Functional analysis is a top-down process of translating system level requirements from the previous step into detailed functional and performance design criteria which are also used during developmental testing and analysis. Critical component analysis is where critical design elements occur, resulting in preliminary and, through iteration, detailed designs. An effective test strategy will “build back up” the other side of the systems engineering V so that the program manager will understand the technical baseline of the development and be better able to inform re-engineering decisions and manage developmental risk. This is done early on through contractor testing (CT) and early developmental testing (DT) applied to component specifications, then through DT applied to functional analysis on functional specifications, then DT, operational assessments and assessment of operational test readiness applied to critical test parameters which are measurable critical system characteristics that, when achieved, enable the attainment of desired operational performance capabilities, and finally, to operational testing (OT) applied to critical operational issues. Through this testing and evaluation process it is the goal of applying STAT, along with input from systems engineering architectures and documentation, and available subject matter expertise that acquisition programs understand and manage their technical baseline.
Enterprise interoperability assessment: a requirements engineering approach
Published in International Journal of Computer Integrated Manufacturing, 2020
Gabriel S. S. Leal, Wided Guédria, Hervé Panetto
The international standard ISO 29148 (ISO/IEC 29148 2011) describes three processes. The Stakeholder Requirements Definition process that have the objective to determine the system requirements that can provide the functions needed by users and other stakeholders in a defined environment. The purpose of the Requirements Analysis process is to transform the stakeholder, requirement-driven view of desired functions into a technical view of a required system that could deliver those functions. These first two processes result in a set of requirements, which flow into the Architectural Design process where the requirements are allocated, decomposed and traced to system elements. In some instances, additional requirement statements should be created to define relationships between the architectural elements of the system, to provide necessary clarity in the context of the lower levels of abstraction of the system elements (ISO/IEC 29148 2011).
Domain-specific requirements analysis framework: ontology-driven approach
Published in International Journal of Computers and Applications, 2019
Shreya Banerjee, Anirban Sarkar
Traceability indicates that user’ requirements specified in Early Requirement Analysis Phase can trace towards requirements specified in Detailed Requirement Analysis Phase. Traceability is defined as the ability to describe and follow the life of an artefact. Artefacts are developed during the software lifecycle in both forward and backwards directions [38]. Bad traceability leads to missing features and not enough test coverage [39]. Therefore, check of traceability is important to deliver a software in which requirements are related to each other. To address this, in this section, several validation rules are proposed for ensuring traceability from the higher level to the lower level abstraction of proposed ODRA.