Reference no: EM132308492
1. Typical constraints on the system may include the following:
a) Cost and schedule
b) Mandated use of commercial off-the-shelf (COTS) equipment
c) Operational environment and use of pre-existing facilities and system elements
d) Engineering preferences
e) Operational interfaces with other systems or organizations.
2. Traceability is not an end goal in and of itself but, rather, a tool that can be used to: (Choose 3)
a) Improve the integrity and accuracy of all requirements, from the system level all the way down to the most fundamental component
b) Allow tracking of the requirements development and allocation and generating overall measures
c) Support easier maintenance and change implementation of the system in the future.
d) System tracking and repair
e) Lifecycle support
f) Cost profile
3. Traceability should be maintained throughout all levels of systems development documentation. Which option is not a traceability activity?
a) Allocate all system requirements to hardware, software, or manual operations, facilities, interfaces, services, or others as required
b) Ensure that all functional and performance requirements or design constraints, either derived from or flowed down directly to a lower system architecture element, actually have been allocated to that element
c) Ensure that traceability of requirements from source documentation is maintained through the project’s life until the verification program is completed and the system is accepted by the customer
d) Provide a test requirement for each mission statement, in order to assure traceability throughout the systems engineering process
e) Ensure that the history of each requirement on the system is maintained and is retrievable.
4. To be non-ambiguous, requirements must be broken down into constituent parts in a traceable hierarchy such that each individual requirement statement is:
a) Clear, unique, consistent, stand-alone (not grouped), and verifiable
b) Traceable to an identified source requirement
c) Inclined to produce a better product
d) Not redundant, nor in conflict with, any other known requirement
e) Not biased by any particular implementation.
5. The primary input to the Systems Architectural Design Process is the project baseline documented during the Requirements Analysis and Stakeholder Requirements Definition Processes, with the following deliverables:
a) Concept Documents
b) System Requirements
c) Architectural Elements
d) System Functions
e) System Functional Interfaces
f) Updated Requirements Verification Processes