Assignment
A.System Needs Statement: Portable, renewable electrical generation, storage, and distribution system capable of outputting 10KVA of electrical power 24 hours per day to includeperiods up to12hours continuously without sunlight. The system will provide a non-governmental organization (NGO) withpower for communications equipment during emergency and crisis situations.
B.System Constraints:Constraints to be adhered to in the design are:
1.Alternating current.
2.Capability to interface into an electrical gridfor communications equipment.
3.Highly restricted availability of fossil fuel in an austere operational environment.
4.Must fit into an Intermodal container (CONEX) with volume of 1530 ft3 (20ft x 9ft x 8.5ft).
5.Total weight less than 1 ton.
6.Air tight covers for electrical components.
7.Stowage structure is the Intermodal container(CONEX).
8.Evaluation parameters:
a.Maximize: (1) portability; (2) power; and (3) endurance; and
b.Minimize: (4) weight; (5) volume; (6) time to deploy; (7) time to stow; (8)
dependency on carbon-based energy sources
Element 4: Feasibility Analysis. The principal output produced from this element is a recommended system solution. The activities in this element include an analysis of alternatives (AoA) and a recommendation. In support of this element the detailed development processes for the AoA at the system-level are revealed. In support of this element the detailed development processes for the feasibility analysis should explicitly address processes which elicit the following.
a. Identification of Proposed Alternatives. The processes through which the conceptual design team conducts what is commonly referred to as trade studies or tradeoff analysis. Definitions for these terms are: (1) trade study is defined as "evaluation of alternatives, based on criteria and systematic analysis, to select the best alternative for attaining determined objectives" (IEEE & ISO/IEC, 2010, p. 379); and (2) tradeoff analysis is defined as "an analytical evaluation of design Page 4 of 6 options/alternatives against performance, design-to-cost objectives, and life cycle quality factors" (IEEE & ISO/IEC, 2010, p. 379). The processes invoked for either term result in a number of alternatives and should be designed such that the method will: (1) ensure choices are developed from a formal methodology (2) include some type of mathematical method of comparison that develops and quantifies a variety of criteria used for comparison; and (3) will prescribe the rationality, objectivity, and repeatability used in the analysis.
b. System Requirements Document (SRD) Compliance. Processes that confirm that each of the alternatives developed during the tradeoff analysis or trade studies satisfies the stakeholder capabilities in the StRS. The process or method should explicitly document where each alternative has met (i.e., in compliance) or has failed to meet (i.e., non-compliance) the capabilities in the StRS.
Element 7: Functional Baseline. The output from the conceptual design stage is the functional baseline. The functional baseline is the product of the system design review Page 6 of 6 (SDR) activities. In support of this element all of the processes used to conduct a formal system design review (SDR) of the system specification should be presented.
a. Verification of the System Specification Functional Requirements. The processes should describe how the review panel verifies that all of the system-level functional requirements are included in the system specification. The process explanation should specify how the review panel verifies that function is defined and performance criteria (MOE/MOP) are established at levels where sub-system design may begin;
b. Verification of the System Specification Non-Functional Requirements. The processes should also include how the review team ensures that relevant non-functional requirements are specified in the system specification. It is mandatory that sustainment concerns (i.e., reliability, maintainability, availability, operability, and testability) are established through sufficient measurable criteria. The processes and rationale for any additional non-functional concerns (i.e., design, sustainment, and viability) should also be addressed;
c. System Specification Requirements Traceability. The processes should include the method by which the review panel verifies that system-level requirement (i.e., functional, non-functional, interface, and performance) has an explicit and clear path traceable back to the MGOS, operational scenarios, and life cycle concepts. The process should ensure that system specification's RBS/RTM is the primary source for this review; and
d. High-Level Review of System Specification. The processes should specify how the review panel conducts a final high-level review of the system specification. The method should specify that the high-level review is a holistic perspective where the review team investigates whether or not the conceptual design emerged as a single design or was the result of a formal analysis of alternatives and how many configuration variations for the selected solution were evaluated. The method should ensure that the review panel evaluates whether or not the solution selection criteria and decisions have been fully documented to allow those who follow to understand the conceptual design logic.