| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | Initial draft |
| Role | Name | Signature | Date |
|---|---|---|---|
| Number | Requirement | Method | Level | Verified By | Status |
|---|---|---|---|---|---|
| 1.1 | Unlock a Bike | Test | System | TC.1 Unlock Within Five Seconds | Passed |
| 1.2 | Detect a Returned Bike | Test | System | TC.2 Detect a Returned Bike | Passed |
| 1.3 | Charge an E-Bike | Analysis, Test | System | TC.3 Charge an E-Bike Overnight | Not Run |
| 4.1.1 | Show Available Bikes | Demonstration | Subsystem | None | Planned-only |
| 10.1 | Fit Within A Footprint | Inspection | System | TC.4 Measure the Dock Footprint | Passed |
| 10.2 | Anchored Without Digging | None | None | Unverified |
| Number | Requirement | Parent | Traced From | Traced To | Satisfied By |
|---|---|---|---|---|---|
| 1.1 | Unlock a Bike | N.1 Find a Bike Nearby | F.1 Rent a Bike | ||
| 1.2 | Detect a Returned Bike | None | |||
| 1.3 | Charge an E-Bike | None | |||
| 4.1.1 | Show Available Bikes | 4.1. Primary Functions | |||
| 10.1 | Fit Within A Footprint | 10. Design Constraints | |||
| 10.2 | Anchored Without Digging | 10. Design Constraints |
| Acronym | Definition |
|---|---|
| ID | Title | Version | Source |
|---|---|---|---|
| [1] |
Record who owns this plan and how it changes. Revise it at each technical review and baseline it with the other review products.
", "labels": [], "props": {}, "created": 1791691702280, "modified": 1791691702281 }, "e464397000004": { "id": "e464397000004", "classId": 21, "name": "Revision History", "number": "1.1.", "description": "Add one row per released version. Summarize what changed.
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | Initial draft |
List the roles that approve this plan, typically the project manager, the chief or lead systems engineer and the customer's technical authority.
| Role | Name | Signature | Date |
|---|---|---|---|
Explain in a few sentences how the technical work on this project is planned, run and controlled. Readers should be able to find who decides what, which reviews gate progress and how the model is kept.
", "labels": [], "props": {}, "created": 1791691702282, "modified": 1791691702282 }, "e464397000010": { "id": "e464397000010", "classId": 21, "name": "Purpose", "number": "2.1.", "description": "Defines how the Bike-Share Dock team plans, performs and controls the systems engineering work, from concept to the acceptance of the first docks.", "labels": [], "props": {}, "created": 1791691702282, "modified": 1791691736282 }, "e464397000012": { "id": "e464397000012", "classId": 21, "name": "Scope", "number": "2.2.", "description": "Name the system of interest and the life-cycle stages this plan covers. State what it does not cover and where that is planned instead (for example the Project Management Plan for cost and staffing).
", "labels": [], "props": {}, "created": 1791691702282, "modified": 1791691702282 }, "e464397000014": { "id": "e464397000014", "classId": 21, "name": "Applicable and Reference Documents", "number": "2.3.", "description": "List the documents this plan depends on: contract or charter, standards, the Concept of Operations, the requirements specification. Link the ones held in this project with traced to.
| ID | Title | Version | Source |
|---|---|---|---|
| [1] |
Describe the system just enough to plan the work: its mission, main elements and the environment it operates in.
", "labels": [], "props": {}, "created": 1791691702283, "modified": 1791691702283 }, "e464397000018": { "id": "e464397000018", "classId": 21, "name": "Mission and Stakeholders", "number": "3.1.", "description": "Summarize the problem the system solves and who has a stake in it. Point to the stakeholder needs in Holarch instead of repeating them.
", "labels": [], "props": {}, "created": 1791691702283, "modified": 1791691702283 }, "e464397000020": { "id": "e464397000020", "classId": 21, "name": "System Context and Boundary", "number": "3.2.", "description": "Show the system, the external systems it works with and what crosses the boundary. A context diagram or an asset diagram from the model works well here.
", "labels": [], "props": {}, "created": 1791691702283, "modified": 1791691702283 }, "e464397000022": { "id": "e464397000022", "classId": 21, "name": "System Breakdown", "number": "3.3.", "description": "Give the top levels of the system hierarchy (segments, subsystems, major assets) and who is responsible for each. Keep the full tree in the model; show the first two or three levels here.
", "labels": [], "props": {}, "created": 1791691702283, "modified": 1791691702283 }, "e464397000024": { "id": "e464397000024", "classId": 21, "name": "Technical Approach", "number": "4.", "description": "Describe how the team turns needs into a verified, accepted system.
", "labels": [], "props": {}, "created": 1791691702283, "modified": 1791691702283 }, "e464397000026": { "id": "e464397000026", "classId": 21, "name": "Life Cycle and Stages", "number": "4.1.", "description": "Name the life-cycle model (for example staged, incremental or iterative) and the stages this project goes through, with the decision that ends each stage.
", "labels": [], "props": {}, "created": 1791691702283, "modified": 1791691702283 }, "e464397000028": { "id": "e464397000028", "classId": 21, "name": "Technical Processes", "number": "4.2.", "description": "For each technical process the project uses (for example the ISO/IEC/IEEE 15288 processes from business or mission analysis to validation), state how it is carried out here, the products it creates and where they live in Holarch. Tailor out the processes that do not apply and say why.
| Process | How it is done here | Products | Owner |
|---|---|---|---|
| Stakeholder needs and requirements definition | |||
| System requirements definition | |||
| Architecture definition | |||
| System analysis | |||
| Verification | |||
| Validation |
Record each deliberate departure from the organization's standard process or the governing standard, with the reason and who approved it.
", "labels": [], "props": {}, "created": 1791691702284, "modified": 1791691702284 }, "e464397000032": { "id": "e464397000032", "classId": 21, "name": "Organization and Responsibilities", "number": "5.", "description": "Show who does the systems engineering work and how it connects to the rest of the project.
", "labels": [], "props": {}, "created": 1791691702284, "modified": 1791691702284 }, "e464397000034": { "id": "e464397000034", "classId": 21, "name": "Roles", "number": "5.1.", "description": "List the technical roles (lead systems engineer, subsystem leads, verification lead, configuration manager) and what each decides. Add the people as Organization or Personnel assets and link them as performers where that helps.
| Role | Name | Responsibilities |
|---|---|---|
| Lead Systems Engineer |
Name the working groups and boards (for example an interface working group or a change control board), their members and how often they meet.
", "labels": [], "props": {}, "created": 1791691702284, "modified": 1791691702284 }, "e464397000038": { "id": "e464397000038", "classId": 21, "name": "Stakeholder Involvement", "number": "5.3.", "description": "State when and how stakeholders take part: reviews, demonstrations, approvals of requirements and of verification results.
", "labels": [], "props": {}, "created": 1791691702284, "modified": 1791691702284 }, "e464397000040": { "id": "e464397000040", "classId": 21, "name": "Technical Reviews and Gates", "number": "6.", "description": "List the reviews that gate progress. For each, give its purpose, entry and exit criteria, the products reviewed and the planned date. Add the reviews as Time milestones so they appear on the schedule.
| Review | Purpose | Entry criteria | Exit criteria | Planned date |
|---|---|---|---|---|
| System Requirements Review | ||||
| Preliminary Design Review | ||||
| Critical Design Review | ||||
| Test Readiness Review |
Describe how requirements are written, reviewed, approved, traced and changed.
", "labels": [], "props": {}, "created": 1791691702285, "modified": 1791691702285 }, "e464397000044": { "id": "e464397000044", "classId": 21, "name": "Writing and Quality", "number": "7.1.", "description": "State the rules requirements must follow and how they are checked. Example: every requirement passes the Quality Check before review; TBDs and TBRs carry an owner and a due date.
", "labels": [], "props": {}, "created": 1791691702285, "modified": 1791691702285 }, "e464397000046": { "id": "e464397000046", "classId": 21, "name": "Traceability", "number": "7.2.", "description": "State the trace links the project keeps (for example need → requirement → function → asset → test case) and how gaps are found. Name the matrix or report that shows them.
", "labels": [], "props": {}, "created": 1791691702285, "modified": 1791691702285 }, "e464397000048": { "id": "e464397000048", "classId": 21, "name": "Configuration and Change Management", "number": "8.", "description": "Explain how the technical baseline is identified, frozen and changed.
", "labels": [], "props": {}, "created": 1791691702285, "modified": 1791691702285 }, "e464397000050": { "id": "e464397000050", "classId": 21, "name": "Baselines", "number": "8.1.", "description": "List the baselines and when each is set (for example the requirements baseline at the System Requirements Review). Use Holarch baselines so later changes can be compared against them.
", "labels": [], "props": {}, "created": 1791691702285, "modified": 1791691702285 }, "e464397000052": { "id": "e464397000052", "classId": 21, "name": "Change Control", "number": "8.2.", "description": "Describe how a change is requested, assessed for impact (suspect links, affected tests), decided and recorded. Name who can approve which kind of change.
", "labels": [], "props": {}, "created": 1791691702285, "modified": 1791691702285 }, "e464397000054": { "id": "e464397000054", "classId": 21, "name": "Interface Management", "number": "9.", "description": "Describe how interfaces are identified, agreed and controlled: who owns each one, where interface definitions are recorded (Conduits and the interface register) and when Interface Control Documents are issued.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000056": { "id": "e464397000056", "classId": 21, "name": "Verification and Validation", "number": "10.", "description": "Summarize how the project shows the system meets its requirements and serves its stakeholders. Put the detail in the Test Plan and keep this section short.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000058": { "id": "e464397000058", "classId": 21, "name": "Verification Approach", "number": "10.1.", "description": "State the verification methods used (inspection, analysis, demonstration, test), the levels at which they apply and how results are recorded. Every requirement gets a method and at least one verifying test case.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000060": { "id": "e464397000060", "classId": 21, "name": "Validation Approach", "number": "10.2.", "description": "State how and when stakeholders confirm the system meets their needs in its intended environment.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000062": { "id": "e464397000062", "classId": 21, "name": "Risk and Decision Management", "number": "11.", "description": "Describe how technical risks and key decisions are handled.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000064": { "id": "e464397000064", "classId": 21, "name": "Risk Management", "number": "11.1.", "description": "State how risks are identified, rated (the likelihood and consequence scales used), assigned an owner and mitigated, and how often the register is reviewed. Keep the risks in the risk register.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000066": { "id": "e464397000066", "classId": 21, "name": "Decision Management", "number": "11.2.", "description": "State which decisions need a formal trade study, the criteria and weighting approach, and how decisions and their rationale are recorded.
", "labels": [], "props": {}, "created": 1791691702286, "modified": 1791691702286 }, "e464397000068": { "id": "e464397000068", "classId": 21, "name": "Technical Measurement", "number": "12.", "description": "List the measures used to track whether the design is converging: measures of effectiveness (MOEs), measures of performance (MOPs) and technical performance measures (TPMs). Add them as Measures with planned values, thresholds and current estimates, and say how often they are updated.
| Measure | Type | Threshold | Goal | Update frequency |
|---|---|---|---|---|
| TPM |
Name the tools the technical work relies on and how the system model is kept trustworthy.
", "labels": [], "props": {}, "created": 1791691702287, "modified": 1791691702287 }, "e464397000072": { "id": "e464397000072", "classId": 21, "name": "System Model", "number": "13.1.", "description": "State what the Holarch model holds, who may change which parts, the naming and numbering conventions, and the model checks run before each review.
", "labels": [], "props": {}, "created": 1791691702287, "modified": 1791691702287 }, "e464397000074": { "id": "e464397000074", "classId": 21, "name": "Other Tools and Data Exchange", "number": "13.2.", "description": "List other engineering tools (CAD, analysis, test) and how data moves between them and the model (for example ReqIF, CSV or Excel exchange).
", "labels": [], "props": {}, "created": 1791691702287, "modified": 1791691702287 }, "e464397000076": { "id": "e464397000076", "classId": 21, "name": "Schedule and Milestones", "number": "14.", "description": "Give the major technical milestones and how they tie to the project schedule. Link to the Gantt chart or timeline rather than repeating it.
", "labels": [], "props": {}, "created": 1791691702287, "modified": 1791691702287 }, "e464397000078": { "id": "e464397000078", "classId": 21, "name": "Appendices", "number": "15.", "description": "Collect supporting material.
", "labels": [], "props": {}, "created": 1791691702287, "modified": 1791691702287 }, "e464397000080": { "id": "e464397000080", "classId": 21, "name": "Acronyms and Abbreviations", "number": "15.1.", "description": "List the acronyms used in this plan. The Acronym Extractor can build this list from the document's text.
| Acronym | Meaning |
|---|---|
List cited documents not already in section 2.3.
| ID | Title | Version | Source |
|---|---|---|---|
| [1] |
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | Initial draft |
| Role | Name | Signature | Date |
|---|---|---|---|
| Number | Requirement | Method | Level | Verified By | Status |
|---|---|---|---|---|---|
| 1.1 | Unlock a Bike | Test | System | TC.1 Unlock Within Five Seconds | Passed |
| 1.2 | Detect a Returned Bike | Test | System | TC.2 Detect a Returned Bike | Passed |
| 1.3 | Charge an E-Bike | Analysis, Test | System | TC.3 Charge an E-Bike Overnight | Not Run |
| 4.1.1 | Show Available Bikes | Demonstration | Subsystem | None | Planned-only |
| 10.1 | Fit Within A Footprint | Inspection | System | TC.4 Measure the Dock Footprint | Passed |
| 10.2 | Anchored Without Digging | None | None | Unverified |
| Number | Requirement | Parent | Traced From | Traced To | Satisfied By |
|---|---|---|---|---|---|
| 1.1 | Unlock a Bike | N.1 Find a Bike Nearby | F.1 Rent a Bike | ||
| 1.2 | Detect a Returned Bike | None | |||
| 1.3 | Charge an E-Bike | None | |||
| 4.1.1 | Show Available Bikes | 4.1. Primary Functions | |||
| 10.1 | Fit Within A Footprint | 10. Design Constraints | |||
| 10.2 | Anchored Without Digging | 10. Design Constraints |
| Acronym | Definition |
|---|---|
| ID | Title | Version | Source |
|---|---|---|---|
| [1] |
State why this plan exists and who uses it. Example: Defines how the team performs and controls the systems engineering effort for WS-1 from concept through acceptance.
" }, "after": { "description": "Defines how the Bike-Share Dock team plans, performs and controls the systems engineering work, from concept to the acceptance of the first docks." }, "by": "Jordan Lee" }, { "t": 1791692423119, "op": "update", "id": "e651561000068", "name": "Verification Matrix", "fields": [ "description" ], "before": { "description": "| Req ID | Method | Level | Event | Owner |
|---|---|---|---|---|
| Number | Requirement | Method | Level | Verified By | Status |
|---|---|---|---|---|---|
| 1.1 | Unlock a Bike | Test | System | TC.1 Unlock Within Five Seconds | Passed |
| 1.2 | Detect a Returned Bike | Test | System | TC.2 Detect a Returned Bike | Passed |
| 1.3 | Charge an E-Bike | Analysis, Test | System | TC.3 Charge an E-Bike Overnight | Not Run |
| 4.1.1 | Show Available Bikes | Demonstration | Subsystem | None | Planned-only |
| 10.1 | Fit Within A Footprint | Inspection | System | TC.4 Measure the Dock Footprint | Passed |
| 10.2 | Anchored Without Digging | None | None | Unverified |
| Number | Requirement | Parent | Traced From | Traced To | Satisfied By |
|---|---|---|---|---|---|
| 1.1 | Unlock a Bike | N.1 Find a Bike Nearby | F.1 Rent a Bike | ||
| 1.2 | Detect a Returned Bike | None | |||
| 1.3 | Charge an E-Bike | None | |||
| 4.1.1 | Show Available Bikes | 4.1. Primary Functions | |||
| 10.1 | Fit Within A Footprint | 10. Design Constraints | |||
| 10.2 | Anchored Without Digging | 10. Design Constraints |