Conceptual Design and Requirements Development Flashcards
Stakeholders
Definition: Stakeholders are individuals or groups who have an interest in, or are affected by, the project or product’s outcome. They include anyone with a direct or indirect influence over the product’s development, usage, funding, or regulatory compliance.
Examples: This category encompasses customers, project sponsors, engineers, regulatory bodies, investors, senior management, suppliers, and even community members. Essentially, anyone impacted by the project’s success or failure.
Role: Stakeholders influence project goals, funding, resources, timelines, and compliance requirements. They may have competing interests, making it important for project teams to balance these interests through effective communication and negotiation.
Focus: Stakeholders are concerned with the project’s overall success, risk management, adherence to policies, and long-term implications.
“Needs Analysis”
- First step in the design process
- Involves getting an inventory of the Operational Deficiencies, Customer Perspectives, and Technological Opportunities
Answering Three Big Questions:
1) “What problem are we solving?” (via Operational Deficiencies)
2) “What could we use to solve it?” (via Technological Opportunities)
3) “What does an acceptable solution actually look like?” (via customer perspectives)
“Concept Development”
Second Step in the Design Process
Refers to the identification of the requirements, mission phases (ConOps, Operational Scenareos) and high-level behaviors (use cases, state machines) needed to actually solve the problem
This comes after the “Needs Analysis”, but before the Preliminary Design
Importance of “Precedence” during Mission and Concept Definition
When looking at what technologies you can leverage for your solution, you need to keep in mind that any technology you develop is going to be a PRECEDENTED system… means it needs to be built up for existing/proven technological solutions
*This is particularly important when examining the question “What could we use to solve it?” via Technological Opportunities
Customers
Scope: All customers are stakeholders, but not all stakeholders are customers. Stakeholders include a wider range of individuals or groups, while customers are specifically the users or buyers.
Interests: Customers prioritize usability, value, and satisfaction, while stakeholders may focus on broader aspects like financial performance, regulatory compliance, project sustainability, and risk.
Decision-making Influence: Customers influence requirements directly related to product functionality, whereas stakeholders may shape the project direction, resources, and timing to align with organizational or regulatory goals.
Stakeholder v. Customers
Definition: Stakeholders are individuals or groups who have an interest in, or are affected by, the project or product’s outcome. They include anyone with a direct or indirect influence over the product’s development, usage, funding, or regulatory compliance.
Examples: This category encompasses customers, project sponsors, engineers, regulatory bodies, investors, senior management, suppliers, and even community members. Essentially, anyone impacted by the project’s success or failure.
Role: Stakeholders influence project goals, funding, resources, timelines, and compliance requirements. They may have competing interests, making it important for project teams to balance these interests through effective communication and negotiation.
Focus: Stakeholders are concerned with the project’s overall success, risk management, adherence to policies, and long-term implications.
Types of Customers
1) Sponsors
2) Active Stakeholders
3) Passive Stakeholders
Technological Opportunity
Operational Need
Operational Deficiency
Operational Need v. Operational Deficiency
Active Stakeholders
Definition: Active stakeholders are customers directly involved in the project’s ongoing activities, decisions, and execution. They frequently engage with the project team and have an immediate influence on project outcomes.
- Emphasizing the fast that they are CUSTOMERS
Examples: This category includes project managers, engineers, product designers, quality assurance teams, regulatory bodies, and sometimes customers who are providing active feedback. Essentially, anyone who participates regularly in project meetings, decision-making, or development processes.
Role: Active stakeholders help define requirements, set priorities, make critical decisions, and directly impact the project’s direction. They are often involved in day-to-day activities and provide regular feedback and support.
Focus: Active stakeholders focus on achieving project goals and milestones, managing risks, ensuring the project stays on schedule and within budget, and addressing issues as they arise.
Passive Stakeholders
Definition: Passive stakeholders are customers who are affected by the project or have a vested interest in its outcome but are not actively involved in its day-to-day processes. Their influence is indirect, and they may only interact with the project team at key points or through feedback channels.
- Emphasizing the fast that they are CUSTOMERS
Examples: This group includes end-users (if not directly involved in development), external investors, community members, and some regulatory or compliance entities that review the project’s output rather than its process. They may also include departments that will handle the product post-launch, such as marketing or customer support.
Role: Passive stakeholders provide feedback on the project outcomes or support activities once the product is released. They may set high-level goals or offer retrospective insights but don’t influence the daily activities.
Focus: Passive stakeholders are generally interested in the final product’s performance, compliance with regulations, alignment with strategic goals, and long-term sustainability.
Active Stakeholders v. Passive Stakeholders
Level of Involvement: Active stakeholders are engaged in the project daily, while passive stakeholders interact only periodically or once the project has reached major milestones.
Influence on Project Direction: Active stakeholders can shape project decisions dynamically, while passive stakeholders influence the project’s broader goals and outcomes.
Feedback Timing: Active stakeholders provide ongoing feedback, whereas passive stakeholders often give input at specific stages or after project completion.
End Users
Problem Statement
Requirements
Any condition, characteristic, or capability that must be achieved and is
essential to the end item’s ability to perform its mission in the environment in which it must
operate.
Stakeholders provide user requirements, captured in the Voice of the Customer and with
context provided by the Concept of Operations.
– Customers
– Users
– etc.
- Given the use cases and the constraints of physics, system modeling and analysis generates
requirements for the system and for the respective system elements.
– Component specifications such that the system will perform as required - Interfaces to other systems or system components will generate interface requirements
Types of Requirements
1) Customer Requirements
2) Functional Requirements
3) Non-functional Requirements
4) Performance Requirements
5) Derived Requirements
6) Stakeholder Requirements
7) Specification Requirements
Customer Requirements
Customer requirements focus specifically on the needs and preferences of the end-user or the client who will directly use or benefit from the system. Customer requirements are a subset of stakeholder requirements and are often more specific to usability, accessibility, and direct functional utility
Extremely dynamic… you can expect these to evolve throughout the design lifecycle
- But you cannot rely on the customer to be forthcoming about these changes
- Need to be proactive about following up, maintaining your understanding of the requirements, and tracking these changes
- MBSE is a great way of tracking this
These are the basis for ‘system validation’
- That’s why it’s so important to maintain your list of customer requirements
- Both your team and design also needs to be extremely flexible so that you can adapt to changing requirements.
Validated through user acceptance testing (UAT) and usability assessments, focusing on customer satisfaction and feature functionality. Customer requirements are often tested in the final stages to confirm they meet user expectations
Generally remain stable once defined but can change in response to feedback on usability, functionality, or performance. Since they directly affect user satisfaction, customer requirements often take priority in iterative design phases to optimize the user experience.
Usually detail specific features or performance criteria. For instance, a customer might require that a system have a specific response time or intuitive interface but may not specify underlying technical or regulatory needs.
Primarily address the features, functionality, and user-friendliness needed to satisfy end-users. They focus on how the system will perform tasks, solve problems, or fulfill needs directly for the customer, often emphasizing functional requirements over non-functional concerns
Derived primarily from the end-user or purchasing organization. These are gathered through direct interactions such as surveys, focus groups, user feedback, and market research to ensure alignment with customer expectations
Focus specifically on the needs, preferences, and expectations of the customer or end-user. These requirements often prioritize user experience, ease of use, and specific features that directly impact the user, offering a more narrow perspective centered around functionality and usability
Functional Requirements
Define what functions
need to be performed to accomplish the objectives.
– Identified via functional analysis techniques such as
FFBDs or SysML Activity Modeling and system design
Typically reside in higher level (e.g.
system or system element)
requirements and are defined earlier
in the life cycle than performance or
non-functional requirements
Example: The Thrust Vector Controller (TVC) shall provide vehicle control about the pitch and yaw axes.
* This statement describes a high-level function that the TVC must perform. The technical team needs to transform this statement into a set of design-to functional and performance requirements
Perspective Getting
Nonfunctional Requirements
Specify physical constraints such as attributes and characteristics
Deal with operational conditions such as safety, system security, reliability, human system integration, environmental, etc.) and life cycle constraints such as maintenance & disposal.
– Identified via standards, guidelines, regulations, etc
Typically result from applicable
standards, guidelines, regulations,
etc.
Example: The TVC shall be serviceable by ground crew personal without requiring hazardous materials
precautions.
Derived Requirements
Highly Design Dependent
[more]
Use Cases and Operational Scenarios provide an
operational capability based foundation for requirements derivation
Stakeholder Requirements
Stakeholder requirements encompass the expectations and needs of ALL individuals or groups impacted by the system, including regulatory bodies, internal team members, and external users (whether they can be considered customers or not). These requirements capture a broader perspective, covering functional needs, environmental conditions, constraints, and performance expectations across the entire system lifecycle.
These encompass the needs and constraints of all parties affected by or involved in the system, including customers, regulatory agencies, investors, technical teams, and organizational leadership. They reflect a holistic view, balancing competing interests from a broad spectrum of stakeholders across the system’s entire lifecycle.
Gathered from multiple channels, including interviews with various departments, regulatory standards, industry best practices, and organizational goals. This includes contributions from groups that may not directly use the system but have an influence or stake in its operation and outcome.
Aim to ensure the system aligns with organizational objectives, legal compliance, operational constraints, and the needs of technical and support staff. Stakeholder requirements also cover non-functional aspects like reliability, maintainability, and regulatory adherence, which may not be of direct interest to customers but are vital for system longevity and performance.
Include both high-level and technical requirements. For example, a stakeholder requirement might stipulate that the system must operate under specific environmental conditions or integrate seamlessly with other systems, as specified by regulatory or internal guidelines.
Tend to evolve as new stakeholders are identified or as the project scope broadens, which can introduce additional constraints or requirements. They are managed continuously to balance diverse interests and evolving regulatory demands.
Verified through compliance testing, risk assessments, and systems validation to ensure all stakeholder needs are met. The system is validated as a whole against these requirements, including reliability and safety.
Stakeholder Requirements v. Customer Requirements
While all customer requirements are stakeholder requirements, not all stakeholder requirements align strictly with customer desires—they may also consider factors critical to other parties, such as maintainability for the technical team or compliance for regulatory bodies.
The distinction helps systems engineers ensure that designs not only meet customer needs but also address the expectations and constraints set by the broader stakeholder ecosystem, balancing functional and non-functional requirements effectively to create a comprehensive solution.
Stakeholder Requirements v. Derived Requirements
Kano Model
Performance Requirements
Define how well the system needs to perform the functions.
– Identified by systems design, modeling and analysis
– Sound like TPMs/KPPs
Typically result from refinement of functional or higher level performance requirements
Specification Requirement
Detailed, formalized statement describing a system or component’s specific attributes, performance criteria, and operational constraints needed to meet the stakeholder and customer needs. Specification requirements serve as a bridge between broad stakeholder needs and technical implementation, capturing the precise details necessary to ensure the system performs as intended in its environment
Operational Requirements
A type of specification Requirement
Operational Requirements specify high-level requirements to achieve system mission
objectives and behavioral interactions
Categories of Specification Requirements
1) Operational Requirements
2) Capability Requirements
3) Non-functional Requirements
4) Interface Requirements
5) Design and Constructions Constraint Requirements
6) Verification Requirements
7) Validation Requirements
House of Quality
Parts of a Requirement
Key Performance Parameters (KPPs)
Extremely Solution Dependent: subset of the performance parameters representing the most critical capabilities and characteristics
Used to communicate to ENGINEERS how EFFECTIVE the system is (Characterize the System in the “voice of the engineer”)
Can be calculated or measured (the inputs in those equations are “Technical Performance Measures”, TPMs)
Measures of Effectiveness (MOEs)
Top-Level measures of success that are closely related to the achievement of mission or objectives; they provide insight into the accomplishment of the mission needs independent of the system design
Used to communicate to CUSTOMERS how EFFECTIVE the system is (Characterize the System in the “voice of the customer”)
Can be calculated or measured (the inputs in those equations are “Measures of Performance”, MOPs)
Measures of Performance (MOPs)
Measurable quantities that can be used to predict/calculate the value of MOEs (for the customers)
All MOPs are TPMs, but not all TPMs are MOPs
Technical Performance Measures (TPMs)
- Refers to any USEFUL measurement that can be made during modeling/simulation/testing
- Sometimes just called “engineering data”
TPMs can be used to calculate EITHER:
1) Key Performance Parameters (KPPs)
2) Measures of Effectiveness (MOEs)
MOPs are a subset of TPMs
Characteristics of Good TPMs
- Should be important and relevant
- Should be relatively easy to measure
- Performance should be expected to improve with time
- If the measure crosses its threshold, corrective action should be known
- The measured parameter should be controllable
- Management should be able to tradeoff cost, schedule and performance
- Should be documented
- Should be tailored for the project
Technical Margins (Margins for TPMs)
Can be established based on three criteria:
1) Historical Data/Statistics
2) Modeling Simulation
3) Expert Opinion
Voice of the Customer (VoC)
VoC represents the needs, preferences, expectations, and desires of the end-users or customers. It’s the qualitative and quantitative input gathered through interviews, surveys, focus groups, feedback, and observation to inform the design process. VoC helps in defining product features, usability, and overall customer satisfaction. Its goal is to ensure that the end product provides the value customers seek and addresses real-world needs effectively.
Examples of VoC inputs: Desired features, ease of use, safety, aesthetics, and specific use-case requirements.
Key role: Drives the requirements and specifications that directly impact user satisfaction and market success.
Voice of the Engineer (VoE)
VoE embodies the technical insights, constraints, capabilities, and innovation potential of the engineering team. Engineers focus on the feasibility of implementing customer requirements within practical constraints like technology limitations, cost, manufacturability, and safety standards. VoE ensures that while customer needs are addressed, they are met within a technically viable and sustainable framework.
Examples of VoE inputs: System limitations, performance optimization, technical standards, reliability, and manufacturability.
Key role: Ensures the product is practical, functional, and compliant with technical and safety standards.
“Voice of the Customer” v. “Voice of the Engineer”
VoC centers on customer needs and usability, while VoE focuses on technical feasibility and engineering constraints.
Successful projects balance both voices, translating customer needs into technically sound requirements that engineers can implement effectively.
Potential conflicts can arise when customer desires exceed technical or budgetary limits, which necessitates negotiation and prioritization to create a viable, customer-satisfactory product.
Balancing VoC and VoE is key in systems engineering, ensuring a product that meets customer needs while staying feasible and reliable.
Visually Tying Customer Requirements to KPPs
Done using a matrix
- Must be completed with the whole team so you get all viewpoints
- Start with the highest priority requirements
- Do not allow the matrix to become too big
- Two primary principles for evaluation:
1) Does it make sense in principle
2) Do we have evidence/observations to support that
Operational Concept v. Concept of Operations v. ConOps
Concept of Operations is the ‘Organization Level’ definition of the system
Operational Concept
Describes the system and its context with both text graphics, but IN THE USER’S TERMINOLOGY
Prepared to support the development of a new or modified/upgraded system. They may be prepared by the customer as part of the request for proposal.
- In this case, they are often called the concept of operations.
- Maintained throughout the product lifecycle
Captured in an “Operational Concept Document” (OCD)
Concept of Operations
Describes how a system, product, or service is envisioned to be deployed, operated, and
maintained.
– Typically produced by the system developer, and so usually does not address system sustainment &
retirement/disposal.
– Produced in collaboration with users & stakeholders to provide a shared vision for the deployment,
operation, and maintenance of the system
ConOps
Communicates to all stakeholders in the users language… the desired characteristics of a system to be developed.
- Provides a mechanism to trigger questions and raise issues regarding operator-related and use-related needs and associated design trades.
A ConOps should provide, in prose and graphics (unlike a specification), a narrative which describes how system is envisioned to fit and function within the operational environment.
* The language and forms of communication, such as graphics, functional flow diagrams, timelines, simulations, and operational mockups should be chosen predominantly to be those that the system users will understand
Benefits of ConOps Development
Primary Benefit: Tells a story for the customer. Create a narrative that describes the system’s intended use.
- act as a catalyst to stimulate the development of
complete, consistent, testable requirements and
designs with emphasis upon those attributes that shape the user-related elements of the system;
– provide guidance and clarification for the development of the subsequent system definition
documentation (e.g., operational
system specifications and interface control drawings);
– form the basis for long range operational planning activities (i.e., staffing, facilities, training, security,
safety, and logistics);
– describe the system behavior(s) that are needed (give best and worst case); and
– reduce cost overrun and schedule slips by defining more accurately the system earlier in the
development stage; and decrease the chances that stakeholder dissatisfaction will terminate the
project
Elements of ConOps
1) Whats: These are the known principal components or elements and top level capabilities
required of the system to perform the necessary functions. The components are described
from an operational point of view. Necessary mission phases or modes may also be described
here.
– The Whats also include descriptions of the external systems with which the system of interest
interfaces, and the external interfaces. Principal internal interfaces are also described.
2) Wheres: These are the environments, such as geographical and physical locations of
customer’s facilities and interfacing systems, within which the capabilities are required to be
performed and supported. A description of the nature of the interfaces with other systems,
organizations, and the environment is also needed.
3) Whens: These describe activities, tasks, flows, precedence, concurrencies, and other
time/sequence-related elements necessary to achieve the mission objectives in each of the
various mission modes and conditions. Whens may also include information as to system
development and operational availability dates, such as program milestones
4) Whos: These describe the interactions among the various human elements within the system
including their interfaces with people external to the system. The OCD and related scenarios
should also identify decision points to include the organizational entity with authority to make
those decisions. Other systems with which this system interoperates are also identified.
5) Whys: These provide the rationale behind any established partitioning of the mission tasks
between the system components and the operators, and the reasoning for specific sequences
of activities or tasks. For example, an important function of an OCD is to provide the rationale
behind the definition of the level of technical expertise required of the system operators. This
will provide a basis for the definition of a set of system requirements and designs with a
consistent level of complexity and sophistication.
6) Hows: These tie together the other elements (the what, where, when, who, and why) to
describe how the system is expected to be used, operated, maintained and, ultimately, retired
in the given environment, under all significant conditions. The emphasis should be on
concepts and should avoid any system design or implementation inferences
Operational Scenarios
An Operational Scenario defines a sequence of events over a period of time representing
some generally complete system functions or transactions that, once initialized, tend to run to
some end.
Operational scenarios are the key to developing a successful Operations Concept Document
Describe the dynamic views of the system’s operation, primarily from the users’ points of view.
* Articulate how the system will operate through various modes and mode transitions, including its expected interactions with the external environment, outlining all important anticipated user, operator, tester, and maintainer interactions that provide the basis and framework for the system analysis and evaluation
“Form”
Definition: Form refers to the physical appearance, shape, and aesthetic characteristics of a product or component. It includes dimensions, color, texture, and overall visual style.
Importance: Form is crucial for customer appeal, user experience, ergonomics, and brand identity. In some cases, form also impacts how components are assembled or fit together within a system.
Example: In consumer electronics, form includes the sleek, minimalistic appearance of smartphones, with specific color schemes and finishes to appeal to users.
“Fit”
Definition: Fit pertains to how well a component or part aligns and interfaces with other parts in the assembly or system. It includes tolerances, alignment, and compatibility with other components.
Importance: Ensuring the correct fit prevents misalignment, wear, and failure in mechanical systems and promotes ease of assembly. Fit is also essential for achieving structural integrity and optimal performance in complex systems.
Example: In automotive manufacturing, ensuring that each part precisely fits within the chassis or engine block is essential to prevent issues like vibrations, misalignment, or assembly difficulties.
“Function”
Definition: Function is the specific purpose, capability, or role of a component or system. It describes what the product is designed to do and how it operates to fulfill its intended use.
Importance: Function is the core reason for a product’s existence and directly impacts its performance, reliability, and utility. Design changes to form or fit should never compromise function.
Example: In a power drill, function includes the ability to rotate a drill bit at varying speeds and torque levels to drill into different materials effectively.
Four factors that determine Form, Fit, and Function
– Stakeholders
– Mission applications
– Performance based objectives
– Operating environmen
Use Cases
Describes the desired services & capabilities of a system from the perspective of the users (actors) who participate in or invoke a system behavior.
*Use Cases provide a good starting point for operations analysis. They feed the ConOps
through support of Operations Scenario development and identification of System Modes
- Created early in system life cycle
– Used during development phase for concept of operations (ConOps)
– Useful view for stakeholders to see mission objectives
A Use Case is a service or behavior the system will perform for an external actor or external system
– The name is always a verb phrase.
– The perspective of the use case is that of the Actors (i.e., users or stakeholders), not the designers
* Services the system must provide, missions the system must be able to accomplish, or capabilities of the system
– not how the system will provide the services, accomplish the mission, or meet the capabilities
– Use cases are invoked by actors
* Primary Actor invokes the use case
– Each use case should accomplish this actor’s need
– The system should respond in a manner that protects all stakeholders’ interests
* Secondary Actors participate in use case
– Primary actors may also be secondary actors
–
Not all behaviors of system are use cases – only system services &/or capabilities invoked or
participated in by external actors
* Identify Use Cases by finishing the statement, “I need to…”
*The Use Case can provide much of the information needed for the scenarios to be
developed for the ConOps
Actor
An actor in a use case may be a human, an organization, or any external system that interacts directly with the system or indirectly through other actors.
Refers to ‘primary stakeholders’ (people, organizations, and even policies)
Two types of actors:
1) Primary Actors
2) Secondary Actors
*These are overlapping sets: Primary actors can also be secondary actors
Form v. Fit v. Function
Comparison
- Form is primarily concerned with aesthetics and physical dimensions.
- Fit focuses on compatibility and alignment with other components.
- Function addresses the practical utility and performance of the component or system.
Relationship and Trade-offs
Design decisions often involve trade-offs between form, fit, and function. For example:
- In some cases, form may be modified to accommodate better fit and function without compromising product appeal.
- In safety-critical systems, function and fit are prioritized over form to ensure reliability and performance.
Primary Actor
Actors that invokes the use case
– Each use case should accomplish this actor’s need
– The system should respond in a manner that protects all stakeholders’ interests
Mission Phases
Phases broadly relate the operational uses of the system or subsystem and should typically
relate to the system in the context of user developed operational scenarios.
Phases relate to user defined operational levels for systems or subsystems. Modes relate to
functional and performance requirements such as ‘the landing gear shall have an engaged
mode’ and ‘the landing gear shall have a cruising mode’. States relate to the actual
implementation of the design
Mission life cycle phases of operation are characterized by performance-based outcomes and objectives. (Can be refined into lower-level outcomes/objectives)
*Phases CONTAIN modes
Mission Phases v. Modes v. Use Cases
Mission Phases contain Modes
Modes contain Use Cases
SBIR v. STTR
OTAs v. SBIR/STTR
These programs fund small businesses (SBIR) and partnerships with research institutions (STTR) to create innovative technologies that meet emerging SPS and CDD needs. SBIR/STTR advances early-stage R&D through a structured, phased approach, focusing on feasibility (Phase I) and prototype development (Phase II). This approach incrementally aligns new technology with specific capability or performance criteria.
OTAs enable rapid prototyping and testing, which is especially useful for refining technologies against SPS and CDD requirements. OTAs allow flexible, milestone-based contracting, supporting iterative testing and adjustment to evolving requirements. They bridge the gap from prototype to initial production, ensuring that technologies meet performance and capability benchmarks quickly and efficiently.
SPS v. CDD
The CDD provides the “what”—defining capabilities that the system must achieve for mission success. The SPS then provides the “how”—detailing exactly how those capabilities will be implemented and measured within the system. This structure ensures that high-level mission objectives flow smoothly into actionable technical requirements, aligning all phases of development from concept to production.
SBIR and STTR programs focus on developing innovative technologies that address the high-level capabilities outlined in the CDD. These programs help small businesses and research institutions create and validate new solutions that can meet CDD needs, laying the groundwork for later development.
OTAs are frequently used to refine and test prototypes against the specific performance metrics outlined in the SPS. Since OTAs allow for rapid adjustments, they are ideal for finalizing system components to ensure they meet SPS standards, bridging the gap between initial concept development and full system deployment.
As projects advance, the high-level capability requirements in the CDD are refined into specific performance metrics in the SPS. Feedback from SBIR/STTR and OTA-funded technology development provides insight into how feasible these capabilities are, potentially leading to SPS adjustments or CDD updates.
If a prototype developed under an OTA does not meet an SPS metric, the testing feedback may prompt adjustments in design or performance requirements. This iterative process ensures that the final system aligns closely with both the capability-driven CDD and the detailed performance metrics in the SPS.
Growth Allowance Tables
Provide recommendations for the growth of planned budgets (mass, power, computer memory) based on statistical based projects
Organized in a table
Parts Tree v. Spec Tree
Solution Domain Hierarchy
Breaks down the elements and considerations into four domains:
1) Requirements Domain Solution
2) Operations Domain Solution
3) Behavioral Domain Solution
4) Physical Domain Solution
As you get to lower and lower levels, the need for documentation increases
Domain-Solution v. Mission Phase Matrix
Column are broken into phases (at a minimum: Pre-mission, Mission, and Post-Mission)
Tabular Approach to writing requirements
