SYSTEM DESIGN CONOPS TECHNICAL REQUIREMENTS DEFINITION Adapted from

SYSTEM DESIGN: CONOPS & TECHNICAL REQUIREMENTS DEFINITION Adapted from NASA Systems Engineering Handbook By Avi Sharma

INTRODUCTION

SYSTEM DESIGN

KEY SYSTEM DESIGN CONCEPTS Successfully understanding and defining the mission objectives and operational concepts are keys to capturing the stakeholder expectations, which will translate into quality requirements over the life cycle of the project. • Complete and thorough requirements traceability is a critical factor in successful validation of requirements. • Clear and unambiguous requirements will help avoid misunderstanding when developing the overall system and when making major or minor changes. • Document all decisions made during the development of the original design concept in the technical data package. This will make the original design philosophy and negotiation results available to assess future proposed changes and modifications against. • The design solution verification occurs when an acceptable design solution has been selected and documented in a technical data package. The design solution is verified against the system requirements and constraints. However, the validation of a design solution is a continuing recursive and iterative process during which the design solution is evaluated against stakeholder expectations.

CONCEPT OF OPERATIONS (CONOPS) Con. Ops: Important component in capturing stakeholder expectations, requirements, and project architecture; first step in stimulating development of requirements & architecture related to user elements of a system • Con. Ops is an important driver in the system requirements and therefore MUST be considered early in the system design processes. Thinking through the Con. Ops often reveals requirements and design functions that might otherwise be overlooked. • (e. g. adding system requirements to allow for communication during a particular phase of a mission. This may require an additional antenna in a specific location that may not be required during the nominal mission)

THE TECHNICAL REQUIREMENTS DEFINITION PROCESS • The customer expectations (needs, wants, desires, capabilities, constraints, external interfaces) are transformed into a definition of the problem, and the product(s) to be developed. READ PROF HILL’S REQUIREMENT TUTORIAL (link listed at end of this briefing) • Level 1 Requirements • Customer expectations and the resulting L 1 requirements are then decomposed into a complete set of validated technical requirements (using “shall” statements) • Level 2 Requirements • The full requirement decomposition is then used to create a design solution for the Product Breakdown Structure (PBS) • STRONG REQUIREMENTS DEFINITION AND DOCUMENTATION IS CRITICAL TO PROJECT SUCCESS • Provide a common means of understanding the solution, to customer and project team • Provide critical implementation details to E&C and manufacturing engineers REQUIREMENTS ARE A MEANS TO COMMUNICATE EXACTLY WHAT PRODUCT IS BEING DESIGNED AND IMPLEMENTED

THE TECHNICAL REQUIREMENTS DEFINITION PROCESS Inputs: Customer Expectations, Con. Ops Outputs: Documented L 2 Requirement s and Measurement s

INPUTS: L 1 REQUIREMENTS AND CONOPS 1) These are L 1 requirements created, based on the customer needs/expectations. These needs/expectations expressed as L 1 requirements, need to be quantified through defining L 2 requirements 2) Conops-derived system functionality/behavior specifications need to be quantified and elaborated with L 2 Requirements as well (e. g. Velociraptor: Obstacle Course; 3 Do. T Spiderbot and Roscoe: Laser Tag; Cube. Sat: Space environment; Super ATech. Top: Child’s everyday use) • Refine the design boundary established by L 1 Requirements • Define and elaborate system constraints/limitations • Identify elements under design control (system elements that cannot be changed) • Establish interfaces (everything with which the system must interact) • Refine functionality and behavior of system, defined initially in Con. Ops

OUTPUTS Technical Requirements: This would be the approved set of requirements that represents a complete description of the problem to be solved and requirements that have been validated and approved by the customer and stakeholders. REQUIREMENTS DOCUMENTATION IS CRITICAL Technical Measures: An established set of measures based on the expectations and requirements that will be tracked and assessed to determine overall system or product effectiveness and customer satisfaction (Section 6. 7 for more details).

3 TYPES OF REQUIREMENTS: FUNCTIONAL, PERFORMANCE, AND INTERFACE • Functional Needs Requirements • What functions need to be performed by system • Performance Requirements • How well these functions must be performed These can be defined in two helpful ways: (1) threshold value (minimum acceptable performance value to complete objective) and (2) baseline level of desired performance. Working with these two terms can help determine design alternatives • Interface Requirements • Design element interface requirements All requirements must survive and perform in the project test and validation environment Read Section 4. 2. 2 for in-depth requirement writing tips

INTERFACE REQUIREMENTS • Interface requirements go beyond the Arxterra App and Control Panel • External interfaces form the boundaries between the product and the environment and can include operational command control, computer to computer, mechanical, electrical, thermal, and data. • It is important to consider how devices will interface with the project and where connections will be made as you will be responsible for the cable routing diagram. • A block diagram depicts the major components, interconnections, and external interfaces of the system. You will also be responsible for creating this for your project.

BENEFITS OF REQUIREMENTS Majority of past project failures can relate back to poor requirement definitions • Well-defined requirements allow for better planning and less back-tracking down the line • Cost and schedule can be better maintained the better the requirements are defined • Final project integration will be smoother because divisions will be more cohesive • Test and Validation will be easier if requirements are written well

JUSTIFYING REQUIREMENTS: REQUIREMENT RATIONALE • System thresholds and baselines should always have a justification, as should all requirements. ØExample: If you were to choose a battery, you must justify why that battery was chosen. This may be through a resource report (mass and power) and/or a tradeoff study. You can’t just pick any battery because you know your project needs a battery. • Was a component chosen solely based on a requirement and/or resource report or does it also offer some other benefit such as a lower cost or faster build time? All of this information must be explicitly documented.

REQUIREMENTS METADATA: WHAT TO INCLUDE!

REQUIREMENTS HIERARCHY AND DECOMPOSITION • The highest level requirements: (L 1) • Customer/Stakeholder needs and expectations • Mission Objectives (Con. Ops) • These requirements decompose: (L 2) • Functional Requirements • Performance Requirements • Interface Requirements • Functional, performance, and interface requirements decompose into: • System Elements • Subsystems • Component (not used in this class) This decomposition and allocation process continues until a complete set of design-to requirements is achieved. At each level of decomposition (system, subsystem, component, etc. ), the total set of derived requirements must be validated against the stakeholder expectations or higher level parent requirements before proceeding to the next level of decomposition. Checking requirements with the customer expectations/Con. Ops/L 1 requirements before proceeding is critical, to verify that the requirements you are writing capture a complete and explicit design solution Send me your requirements before they are due so I can help you!

TRACEABILITY OF REQUIREMENTS • The lowest level requirements should be able to be traced all of the way back to customer expectations • Ensures that each requirement contributes to meeting customer expectations/Con. Ops • Requirements with no lower level • Invalid! These will not meet the objective. • Lower level requirements that are not traceable to higher level requirements • Also invalid! These will result in unjustified overdesign. Every requirement must be justifiable, which means it must trace the full length of the requirement hierarchy

Key Diagram

CHANGING REQUIREMENT S • Changes to requirements/system constraints are inevitable; HOWEVER all changes must be analyzed to determine the effect on requirements higher and lower in the hierarchy • Any and all requirements, including changes to existing requirements, requires justification and approval • Include all necessary supporting data • Does the requirement link to other requirements? • How was the requirement justified? • To meet a demand or through experiment, testing, resource reporting, or a tradeoff study • Avoid TBD/TBR when determining requirements • This is due to the massive time constraint of our semester

READING NASA Systems Engineering Textbook, Chapter 4 (System Design), Appendix C, Section 6. 2. 1. 2: http: //www. acq. osd. mil/se/docs/NASA-SP-2007 -6105 -Rev-1 -Final 31 Dec 2007. pdf Professor Hill’s Engineering Method Lecture: http: //web. csulb. edu/~hill/ee 400 d/Lectures/Week%2002%20 Engineering%20 Method/b_NASA%20 System%20 Engineering%20 Method. pdf Professor Hill’s Requirements Lecture: http: //web. csulb. edu/~hill/ee 400 d/Lectures/Week%2003%20 Creativity/b_Req uirements. pdf