Plan & Deliver
SE Process Guides
Follow a project through a systems engineering process (Kossiakoff, ISO/IEC/IEEE 15288, NASA, DoDDepartment of Defense The US Department of Defense., MIL-STD-499B or the Vee model) phase by phase, with checks read from the model, review gates, milestones and review packages.
The SE Process page guides a project through a systems engineering process of your choice. Each process divides the life cycle into phases (or stages); for each phase the page lists checks that Holarch reads from the model, such as needs traced to requirements or functions allocated to components, grouped by the process's steps or processes, and links each check to the page where the work is done. The processes are described under Processes; their names and structure follow the cited sources, and the descriptions, checks and templates are Holarch's own.
Concepts
- Process: the method the guide follows, chosen when you turn it on and changeable later. Each process keeps its own current phase, ticks and gates.
- Stage and phase: the parts of the life cycle. A phase has its own aim and checks; a stage groups phases.
- Step or process card: the activities of a phase, such as Kossiakoff's four steps or the 15288 technical processes. Only cards with checks in the viewed phase are shown.
- Check: one line under a step. A check read from the model shows ✓ (done), ◐ (partly done) or ○ (not started) and a count, for example "3 of 5 needs traced". A check the model cannot show has a checkbox; ticking it records who ticked it and when.
- Current phase: the phase the project is in. Any phase can be viewed; the current one is marked Current.
- Gate: a review in or at the end of a phase. Its date is a milestone (a Time entity labeled Milestone), and its documents can be gathered in a review package (a Compilation). Processes with named reviews, such as a Preliminary Design Review, list entry criteria under each review.
How to use it
When and why
Use the guide when a project follows a phased life cycle, for a course or for a real program, and you want to see what each phase still needs. It does not replace the model or the other pages: it reads them. Turning it on changes nothing in the model.
Turn on the process guide
- In the rail, open Plan & Deliver → SE Process.
- Select a process in the list and click Use This Process. The life cycle appears with the first phase as the current phase.
- To undo, press ⌘Z / Ctrl+Z. The choice is saved with the project and shared with its members.
Switch to another process
- In the life-cycle card, choose another process in Process.
- The guide opens that process where you left it, or at its first phase. The previous process's phase, ticks and gates are kept and come back when you switch back. Undo reverses the switch.
Work through a phase
- Click a phase in Life cycle. The percentage on each phase is the share of its checks that are done.
- Read the step or process cards. Start with the checks marked ○.
- Click Open next to a check to go to the page where the work happens, for example Requirements, Quality, Traceability Matrix, Functional Analysis, Interface Register, RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result. or Risk Register.
- Come back to SE Process. Checks read from the model update as soon as the model changes.
- Tick the checkboxes of manual checks when the work is done, for example after the stakeholders agree on the needs.
- When the phase is complete, select the next phase and click Make Current Phase.
Hold a phase gate
- Select the phase and find Phase gate (or Reviews and gates) at the bottom.
- Click Add Gate Milestone. Holarch creates a Time entity named after the phase or review, for example "Needs analysis review", labeled Milestone. Open it to set its date; it then shows on the Project Management calendar and under Upcoming Dates.
- Click Create Review Package. Holarch creates a Compilation named after the phase or review that includes the project's documents of the types it needs. Open it to add more documents or export it.
Write the concept-stage documents
- Open Documents and click + New Document. The Create Document wizard opens.
- Choose the type Needs Analysis Document, Concept Exploration Document or Concept Definition Document and enter a name.
- Click Next, choose the template (With Guidelines) or (Outline), and click Finish.
- Write each section. The guidance says which model entities to reference, such as the Statements for operational objectives or the Trade Study for the comparison of candidate concepts.
Worked example: a weather station
A team starts a weather station project with the Kossiakoff process. In Needs analysis they record five needs as Statements, add two Measures of effectiveness and write a Needs Analysis document; four checks turn ✓. In Concept exploration they derive twelve requirements, trace each need to them (the trace check shows "5 of 5 needs traced"), run the quality check, draw an FFBDFunctional Flow Block Diagram A diagram of functions in the order they run, with branches, loops and parallel paths. and compare three candidate stations in a Trade Study. In Concept definition they approve the requirements, allocate them to functions, define the components as Assets, allocate the functions, record the interfaces and the decision, then add the gate milestone and create the review package for the review.
Tips and good practice
- Record needs as Statements and connect them to requirements with traced to: the needs checks count those links.
- Run the Quality check before each gate; checks use the stored quality score.
- Concept phases ask for little physical detail. Checks about components, allocation and interfaces start in Concept definition.
Common mistakes
- Recording needs as Requirements: needs are Statements that are not Requirements. A Requirement counts as a requirement, not as a need.
- Expecting document text to count as needs: document sections are Statements too, so a Statement inside a document counts as a need only once it is traced (for example traced to a requirement or a stakeholder).
- Expecting the review package to update itself: it includes the documents that exist when it is created. Add later documents in the Compilation.
How it connects to other features
The checks read Requirements, Statements, Actions, Assets, Conduits, Risks, Decisions, Measures, Issues and Baselines, the Quality results, the RVTM and the Trade Studies. Milestones appear in Project Management. Review packages are Compilations.
The SE Process page
- Process list and Use This Process: choose a process and turn the guide on (one undo step).
- Life cycle: the stages and their phases, each with its share of checks done. Current marks the current phase. Process switches to another process. Stop Using turns the guide off after a confirmation: "The process, phase, ticked checks and gate links are removed from this project. Milestones, review packages and documents stay. Undo restores the guide."
- Phase heading: the phase name, its stage, its aim and Make Current Phase (shown for any phase other than the current one).
- Step or process cards: each with its checks and Open links.
- Phase gate or Reviews and gates: each review with its entry criteria, Add Gate Milestone and Create Review Package, or links to the milestone and package once created.
Processes
Kossiakoff SE method
Based on Kossiakoff et al., Systems Engineering Principles and Practice. Three stages in eight phases: concept development (needs analysis, concept exploration, concept definition), engineering development (advanced development, engineering design, integration and evaluation) and post-development (production, operation and support). In every phase four steps repeat: requirements analysis (what must the system do, and how well), functional definition (which functions achieve it), physical definition (which components perform them) and design validation (does the design meet the need).
| Phase | What the checks look for |
|---|---|
| Needs analysis | Needs as Statements, Measures of effectiveness, top-level functions, a Concept of Operations document, assets for the system context, a Needs Analysis document; feasibility, a technology survey and stakeholder agreement by hand |
| Concept exploration | Requirements, needs traced to requirements, quality-checked requirements, decomposed functions, a functional flow, a Trade Study, a Concept Exploration document, measures; the shortlist by hand |
| Concept definition | Approved requirements, quality score 67 or better, requirements allocated to functions, decomposed functions, assets, functions performed by a component, interfaces, a justified decision, risks with a mitigation, a Concept Definition document |
| Advanced development | A baseline, no open suspect links, inputs and outputs, risks caused by a component, measures, risks with a mitigation; proof of the unproven parts by hand |
| Engineering design | Requirements allocated to components, no open suspect links, functions performed by a component, interfaces with both ends connected, verification methods, verifiers (test cases or analyses); the N² check and detailed design by hand |
| Integration and evaluation | No open suspect links, requirements tested and verified, failed verifications recorded as issues; scenarios and integration by hand |
| Production | A baseline, no open suspect links, requirements verified; procedures, design release and delivery by hand |
| Operation and support | Issues; feedback, procedures, maintenance and in-service evaluation by hand |
ISO/IEC/IEEE 15288
Based on ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes. Six stages: concept, development, production, utilization, support and retirement, each ending at a decision gate. Each stage shows the technical processes that apply there, then the technical management processes in a second row.
| Stage | What the checks look for |
|---|---|
| Concept | Trade studies, needs and their stakeholders, a Concept of Operations, measures, requirements traced from the needs and quality-checked, top-level functions, system elements, a SEMP, a justified decision, risks; the problem statement, feasibility and stakeholder agreement by hand |
| Development | Approved requirements at quality 67 or better, functional flows, allocations, interfaces with both ends, components, an ICD, measures, verification methods, verifiers and results, needs validated, tasks, trade studies, mitigations, baselines, suspect links, failures as issues; implementation and integration by hand |
| Production | Requirements verified, operating procedures, a baseline, defects as issues; production and delivery by hand |
| Utilization | Issues and measures; operation, in-service validation and new needs by hand |
| Support | An Integrated Logistics Support Plan, issues, suspect links; records by hand |
| Retirement | A final baseline; disposal and archiving by hand |
NASA project life cycle
Based on NPR 7123.1, NASA Systems Engineering Processes and Requirements and NASA/SP-2016-6105 Rev2, NASA Systems Engineering Handbook. Formulation (Pre-Phase A, Phases A and B) and implementation (Phases C to F); each phase ends at a key decision point, KDP A to KDP F. The cards are the 17 common technical processes in three groups: system design, product realization and technical management.
| Phase | Reviews and what their entry criteria look for |
|---|---|
| Pre-Phase A: Concept studies | MCR: expectations recorded, a Concept of Operations, alternatives compared, risks |
| Phase A: Concept and technology development | SRR: requirements traced from the expectations and quality-checked, a SEMP. MDR/SDR: requirements allocated to functions, functions to elements, a justified decision |
| Phase B: Preliminary design | PDR: requirements allocated to components, interfaces, TPMs, mitigations, verification methods |
| Phase C: Final design and fabrication | CDR: interfaces with both ends, verifiers, no suspect links, a baseline. SIR: test cases; readiness by hand |
| Phase D: Integration and test, launch | TRR, SAR, ORR, FRR: a test plan, verifiers, requirements verified, failures resolved, procedures, mitigations |
| Phases E and F | PLAR, DR, DRR: by hand |
DoD acquisition life cycle
Based on the DoDDepartment of Defense The US Department of Defense. Systems Engineering Guidebook (2022) and DAU guidance; review names and sequence as in IEEE 15288.2. Five phases, with Milestone A after materiel solution analysis, B after technology maturation and risk reduction, and C after engineering and manufacturing development. Each review lists entry criteria and exit criteria (action items recorded as issues, an agreed baseline). The cards are the eight technical and eight technical management processes.
| Phase | Reviews |
|---|---|
| Materiel solution analysis | ASR |
| Technology maturation and risk reduction | SRR, SFR, PDR |
| Engineering and manufacturing development | CDR, TRR, SVR/FCA, PRR |
| Production and deployment | PCA |
| Operations and support | Phase gate |
MIL-STD-499B process loop
Based on MIL-STD-499B (draft, 1994), Systems Engineering. The same process repeats in five acquisition phases (concept exploration and definition through operations and support, with Milestones I to III): requirements analysis, functional analysis and allocation, synthesis, and systems analysis and control. The requirements loop (requirements allocated to functions, suspect links), the design loop (functions and requirements allocated to the design) and verification have their own cards.
Vee model
The Vee model as commonly taught. Left side: concept of operations, system requirements, high-level design, detailed design. Bottom: implementation. Right side, from the bottom: unit verification, subsystem verification, system verification, system validation, operations and maintenance. Each right-side phase names the left-side phase it checks, and Verification links shows each pair's status: needs validated, requirements verified, and subsystems and lowest-level components related to a verifying test (verified by).
Limits
- One process is active per project at a time. The processes and their phases are fixed.
- Checks count entities and links; they do not judge content. A ✓ means the work is recorded in the model, not that it is good.
- Reviewers and viewers see the guide but cannot change it.
Last updated October 10, 2026