Document 3 System Requirements - The Systems Engineering Process | SIE 554A, Exams of Engineering

Download Document 3 System Requirements - The Systems Engineering Process | SIE 554A and more Exams Engineering in PDF only on Docsity!

DaRC Solutions

Document 3 System Requirements Document

Group 8

David Juenemann, Reed Nyght, Carla Sayan

3. System Requirements Document

3.1. Configuration Management Date Name Item 10/05/08 DaRC Solutions Rev. - 10/06/08 DaRC Solutions Rev. A 10/07/08 DaRC Solutions Rev. B 11/26/08 DaRC Solutions Rev. C 11/27/08 DaRC Solutions Rev. D 12/07/08 DaRC Solutions Rev. E

Table Of Contents

3. System Requirements Document..................................................................................... 1 3.1. Configuration Management.......................................................................................... 1 3.2. The System Requirement.............................................................................................. 3 3.3. Input/Output and Functional Requirement................................................................... 3 3.3.1. System Time Scale ..................................................................................................... 3 3.3.4. System Outputs .......................................................................................................... 4 3.3.5. System Output Trajectories ....................................................................................... 4 3.3.6. System Matching Functions ...................................................................................... 5 3.4. Technology Requirement.............................................................................................. 5 3.4.1. Available Money ....................................................................................................... 5 3.4.2. Available Time .......................................................................................................... 5 3.4.3. Available Components .............................................................................................. 5 3.4.4. Available Techniques ................................................................................................ 5 3.4.5. Required Interfaces ................................................................................................... 5 3.4.6. Form, Fit and other Restrictions .............................................................................. 5 3.5. Input/Output Performance Requirement....................................................................... 6 3.5.1. Definition of Performance Figures of Merit ............................................................. 6 3.5.2. Lower, Upper, Baseline, and Scoring Parameters ................................................... 6 3.5.2.1. Probability of Kill................................................................................................... 7 3.5.2.2. Satellite Size ............................................................................................................ 7 3.5.3. Performance Figures of Merit Weighting Criteria ................................................... 8 3.6. Utilization of Resources Requirement.......................................................................... 8 3.6.1. Definition of Resource Figures of Merit ................................................................... 8 3.6.2. Lower, Upper, Baseline, and Scoring Parameters ................................................... 8 3.6.2.1. Schedule.................................................................................................................. 9 3.6.2.2. Cost to Develop..................................................................................................... 10 3.6.2.3. Cost Per Unit ........................................................................................................ 10 3.6.2.4. COTS Utilization ................................................................................................... 11 3.6.2.5. Ease of Use........................................................................................................... 12 3.6.2.6. Lifetime................................................................................................................. 12

3.2. The System Requirement

The System Design Problem entails stating the following requirements. Input/Output and Functional Requirement Technology Requirement Input/Output Performance Requirement Utilization of Resources Requirement Trade-Off Requirement System Test Requirement

3.3. Input/Output and Functional Requirement

The Input/Output and Functional Requirements consist of the following: TPUC – System Time Scale IPUC – System Inputs ITPUC – System Input Trajectories OPUC – System Outputs OTPUC – System Output Trajectories MPUC – System Matching Functions

3.3.1. System Time Scale

TPUC is the time scale for ALASM is expressed in milliseconds. The flight life is expected not to exceed 10 minutes. This becomes 10 minutes * 60 seconds/minute * 1000 milliseconds/second = 600,000 milliseconds. TPUC = IJS [0 – 600,000] 3.3.2. System Inputs IPUC0 represents the set of system inputs for ALASM. There are three inputs. IPUC0 = IPUC1 x IPUC2 x IPUC IPUC1 is a set of data representing current target position. IPUC1 = TargetPosition = {TargetLocation, TargetVelocity, TargetObserveTime} TargetLocation = IJS{1-N} TargetVelocity = IJS{1-N} TargetObserveTime = IJS{1-N} IPUC2 is a set of data representing current ALASM position (Transfer Alignment). IPUC2 = MissilePosition = {MissileLocation, MissleVelocity, MissileObserveTime} MissileLocation = IJS{1-N} MissileVelocity = IJS{1-N} MissileObserveTime = IJS{1-N} IPUC3 is a set of data representing the security code. IPUC3 = SecurityKey = {Launch}

Launch = IJS{1-N} 3.3.3. System Input Trajectories ITPUC is the set of input trajectories for ALASM. The set of all possible inputs IPUC over the time scale TPUC are identified below. ITPUC = {f: f X FNS (TPUC, IPUC)}; If Transfer Alignment is not received a LAR cannot be calculated. If the security code is not received or correct ALASM will fail BIT.

3.3.4. System Outputs

OPUC represents the set of system outputs for ALASM. There are three outputs. OPUC = OPUC1 x OPUC2 x OPUC where OPUC1 is a set of data representing the LAR region, in this case 4 points of a rectangle at the expected launch altitude where “0” is null data and “1” is data received. OPUC1 = LAR = {(Lat1, Long1), (Lat2, Long2), (Lat3, Long3), (Lat4, Long4)} Lat1 = IJS{-90 - 90}; Long1 = IJS{-180 - 180}; Lat2 = IJS{-90 - 90}; Long2 = IJS{-180 - 180}; Lat3 = IJS{-90 - 90}; Long3 = IJS{-180 - 180}; Lat4 = IJS{-90 - 90}; Long4 = IJS{-180 - 180} where OPUC2 is a set of data displayed to the pilot for missile status (BIT) where “0” is null data and “1” is data received. OPUC2 = MissileStatus = {MissileReady, MissileFail} MissileReady = {0,1} MissileFail = {0,1} where OPUC3 is a set of data from the seeker showing the target, latest aim point and expected impact position prior to impact to assist with post-flight analysis where “0” is null data and “1” is data received. OPUC3 = TargetDestroy = {TargetImage, TargetAimpoint, TargetImpactPosition} TargetImage = {0,1} TargetAimpoint = {0,1} TargetImpactPosition = {0,1}

3.3.5. System Output Trajectories

OTPUC is the set of output trajectories for ALASM. OTPUC is the set of all possible outputs (OPUC) over the time scale (TPUC). OTPUC = {f: f ^ FNS(TPUC, OPUC); If any data sets contained within LAR report “0” or null data MissileFail reports “0”. Missile status will be indicated only after BIT is performed.

3.5. Input/Output Performance Requirement

3.5.1. Definition of Performance Figures of Merit

The overall Performance Figure of Merit is defined as IF0P0 and is mathematically represented as follows: IF0P0 = (ISF1P0 * IW1P0) + (ISF2P0 * IW2P0) +... + (ISFmP0 * IWmP0) where n = the total number of I/O Performance Criteria and ISFiP0 = ISiP0(IFiP0(FSD)) for i = 1 to m.

3.5.2. Lower, Upper, Baseline, and Scoring Parameters

In this section, the following naming convention is used: The initial letter “I” indicates the name is for an Input/Output Performance Requirement. The terminal P0 indicates the name involves the initial iteration for the ALASM system. IFiP0 = the ith figure of merit measured per the test plan, IBiP0 = the baseline value for the ith figure of merit, IFXiP0 = the measured value for the ith figure of merit, ILTHiP0 = lower threshold for the ith figure of merit, IRiP0 = ranking of importance from 1 to 10, ISFiP0 = score for the ith figure of merit, ISiP0 = scoring function for the ith figure of merit, ISLiP0 = slope for the ith figure of merit, IUTHiP0 = upper threshold for the ith figure of merit, IWiP0 = weight for the ith figure of merit SSF = standard scoring function

3.5.2.1. Probability of Kill

Probability of Kill of the system is the determination the system can effectively destroy the intended target. This requirement if a function of multiple functions located in Document 2, Section 2.5, which independently is either present or not included. When combined they each contribute to overall system performance. Score: IS1P0 = SSF (ILTH1P0, IB1P0, IUTH1P0, ISL1P0) Units % probability of destroying target Lower Threshold ILTH1P0 95 Baseline IB1P0 96 Upper Threshold IUTH1P0 100 Slope ISL1P0 7

3.5.2.2. Satellite Size

Satellite Size is the physical frontal area that can be observed by the seeker. Score: IS2P0 = SSF (ILTH2P0, IB2P0, IUTH2P0, ISL2P0) Units Square Feet Lower Threshold ILTH2P0 100 Baseline IB2P0 120 Upper Threshold IUTH2P0 150 Slope ISL2P0 -0.

UFXiP0 = the measured value for the ith^ figure of merit, ULTHiP0 = lower threshold for the ith^ figure of merit, URiP0 = ranking of importance from 1 to 10, USFiP0 = score for the ith^ figure of merit, USiP0 = scoring function for the ith^ figure of merit, USLiP0 = slope for the ith^ figure of merit, UUTHiP0 = upper threshold for the ith^ figure of merit, UWiP0 = weight for the ith^ figure of merit, and SSF = standard scoring function

3.6.2.1. Schedule

Schedule represents the amount of time to develop the system and is measured as the probability of finishing within the given timeframe. Score: US1P0 = SSF (ULTH1P0, UB1P0, UUTH1P0, USL1P0) Units % probability of meeting the schedule Lower Threshold ULTH1P0 35 Baseline UB1P0 42 Upper Threshold UUTH1P0 48 Slope USL1P0 -0.

3.6.2.2. Cost to Develop

Cost to Develop represents the approximate cost incurred to develop the system and is measured as the probability of meeting the cost objectives. Score: US2P0 = SSF (ULTH2P0, UB2P0, UUTH2P0, USL2P0) Units Dollars (USD) Lower Threshold ULTH2P0 50,000, Baseline UB2P0 75,000, Upper Threshold UUTH2P0 100,000, Slope USL2P0 -5E-

3.6.2.3. Cost Per Unit

Cost Per Unit is the final anticipated cost of the system and is measured as the probability of meeting the cost objectives.. Score: US3P0 = SSF (ULTH3P0, UB3P0, UUTH3P0, USL3P0) Units Dollars (USD) Lower Threshold ULTH2P0 10,000, Baseline UB2P0 17,000, Upper Threshold UUTH2P0 25,000, Slope USL2P0 8E-

3.6.2.5. Ease of Use

Ease of Use is the perceived difficulty of using the system as voiced by BARPA and/or BARPA-designated representatives, such as potential end-users and is measured as the probability of meeting the established thresholds. Score: US5P0 = SSF (ULTH5P0, UB5P0, UUTH5P0, USL5P0) Units Scale from 1 to 10 (1 being difficult, 10 being the simplest) Lower Threshold ULTH4P0 1 Baseline UB4P0 8 Upper Threshold UUTH4P0 10 Slope USL4P0 0.

3.6.2.6. Lifetime

Lifetime is the calculated life expectancy which uses reliability and quality data for critical components and is measured as the probability of meeting the requirement. Score: US6P0 = SSF (ULTH6P0, UB6P0, UUTH6P0, USL6P0) Units Years Lower Threshold ULTH4P0 10 Baseline UB4P0 12 Upper Threshold UUTH4P0 15 Slope USL4P0 9

3.6.2.7. Growth Opportunities

Growth Opportunities is the perceived ability to upgrade or add functionality to the system with relative ease and is measured as the probability to meet the specified objectives. Score: US7P0 = SSF (ULTH7P0, UB7P0, UUTH7P0, USL7P0) Units Scale from 1 to 10 (1 being not possible, 10 being high potential) Lower Threshold ULTH4P0 1 Baseline UB4P0 6 Upper Threshold UUTH4P0 10 Slope USL4P0 0.

3. simulation analysis shows acceptable performance The system failure modes include:
4. does not pass BIT
5. system design takes more resources than originally planned causing severe cost overruns forcing cancellation of RFP
6. Decision to abort mission prior to launch
7. sub-component or sub-system failure in flight

3.8.1.2. Test Trajectory 1

Test focus: Flight Trajectory Simulation To determine if the system performs as designed, non-conservative simulations will be conducted. Non-conservative consists of modeling all parameters at their lowest/highest value causing the probability of failure to increase. Sensitivity analyses will be conducted to determine which parameters most affect the mission outcome.

3.8.2. Input/Output Performance Tests

Probability of Kill will be determined via simulation/analysis. Satellite Size will be determined via analysis and testing. Seeker component testing will validate analyses and performance of the seeker.

3.8.3. Utilization of Resources Tests

Schedule represents the amount of time to develop the system. The program scheduler will track time. Time can be from 35 to 48 months. Cost to Develop represents the approximate cost incurred to develop the system. DaRC Solutions will track costs on a week-to-week basis. Cost can range from $50,000,000 to $100,000,000. Cost Per Unit represents the approximate cost to procure hardware, build and test the system. DaRC Solutions will use Estimators and actual costs on similar systems to determine cost. Cost can range from $10,000,000 to $25,000,000. COTS Utilization is the approximate percentage of the total system which is constructed from Commercial Off the Shelf parts. COTS can range from 0 to 10. Ease of Use is the perceived difficulty of using the system as voiced by BARPA and/or BARPA-designated representatives, such as potential end-users. Ease of Use can range from 1 to 10. Lifetime is the calculated life expectancy which uses reliability and quality data for critical components and has a range of 10 to 15 years. Growth Opportunities is the perceived ability to upgrade or add functionality to the system with relative ease. Growth Opportunities can range from 1 to 10.

3.9. Rationale for Operational Need

Rationale was provided in the RFP presented to DaRC Solutions by BARPA. This system is to provide BARPA a capability to destroy LEO satellites which have malfunctioned. Some satellites carry hazardous and/or toxic materials, which if they survive re-entry, could cause an environmental disaster.