How Systems Engineers Use iPhone Notes for Requirements and Architecture

Systems engineering is the discipline of managing complexity. The systems engineer is responsible for ensuring that all elements of a complex system — hardware, software, firmware, human operators, and external interfaces — work together to satisfy the mission requirements. This requires relentless documentation of decisions, rationale, and dependencies that no individual discipline engineer sees in full.

Why Systems Engineers Need Rigorous Notes

Systems engineering decisions are often made in meetings, during trade studies, or through stakeholder negotiations — not in formal design tools. The decision to allocate a weight budget between two subsystems, the rationale for selecting a specific interface protocol, the acceptance of a requirement that the customer only partially articulated — these decisions shape everything that follows. Notes capture them before they are forgotten.

Requirements Notes

Requirements management is the core of systems engineering:

• Requirement ID — from the requirements management tool
• Requirement text — as stated, including version
• Source — customer document, regulation, derived internally
• Rationale — why this requirement exists
• Allocation — which subsystem(s) are responsible for satisfying it
• Verification method — test, analysis, inspection, or demonstration
• Open issues — ambiguities or conflicts that need resolution
• Stakeholder who owns the clarification — who must answer the open issue

Requirements notes capture the interpretation and allocation decisions that turn a requirements document into a buildable system.

Architecture Decision Notes

Architecture decisions have long-lasting consequences:

• Decision being made — what architectural question was resolved
• Options considered — at least two alternatives evaluated
• Evaluation criteria — what factors drove the comparison
• Trade study results — quantitative or qualitative comparison
• Decision made and rationale — what was chosen and why
• Risks accepted — what risks come with this choice
• Who decided — authority level and date

Architecture decision notes are the foundation of Architecture Decision Records (ADRs) that teams formalize — the note is the raw material.

Interface Notes

Interface control is where integration failures originate:

• Interface ID — between which systems or components
• Interface type — mechanical, electrical, software, thermal, human
• Interface definition — connector types, signal names, protocols, voltage levels, data formats
• Open interface issues — what is not yet defined or agreed
• Owner of each side — which subsystem team controls each interface
• Freeze date — when the interface is baselined

Interface notes track the evolving state of interfaces before the Interface Control Document (ICD) is formal.

Trade Study Notes

Trade studies support major design decisions:

• Trade study question — what decision is being made?
• Alternatives — options being evaluated
• Figures of merit — evaluation criteria and their weights
• Data sources — where analysis data came from
• Scoring results — how each alternative performed
• Sensitivity analysis — does the winner change if weights change?
• Recommendation and rationale — what to do and why

Trade study notes capture the analytical rigor behind decisions that otherwise appear arbitrary to downstream engineers.

Risk Notes

Systems engineering manages risk at the program level:

• Risk ID — unique identifier
• Risk description — what could happen
• Likelihood — probability assessment
• Consequence — impact if risk materializes
• Risk level — combined score
• Mitigation — what action reduces likelihood or consequence
• Residual risk — after mitigation
• Owner — who is responsible for monitoring and mitigating

Risk notes feed the formal risk register and ensure risks don't fall through organizational cracks.

Stakeholder Notes

Systems engineers interface with customers, end users, regulatory bodies, and internal discipline teams:

• Stakeholder name and organization
• Requirements or concerns they raised — verbatim where important
• Commitments made — what was promised
• Follow-up actions — who does what by when
• Context — why this stakeholder's view matters to the system design

Stakeholder notes document the voice of the customer through the layers of a complex program.

FAQ

Q: How do I note a requirements conflict between two stakeholders? A: Document both positions, the conflict clearly, who has authority to resolve it, and the resolution timeline. Unresolved requirements conflicts are among the most common sources of program cost growth.

Q: Should I note informal technical guidance from the customer? A: Yes — informal technical guidance often precedes formal direction by weeks or months. Note it with source, date, and context. When the formal direction arrives, compare it to your notes.

Q: How do I handle notes from design reviews? A: Note action items with specific owner, description, and due date. Design review action notes are more useful than comprehensive meeting minutes because they focus on what must change.

Q: What about notes for verification planning? A: A verification planning note per requirement — what method, which organization, what environment, what success criteria — ensures verification can actually be demonstrated before the program reaches IV&V.

Q: How do I note emerging requirements not yet in the formal baseline? A: Tag them as "candidate requirements" with source and preliminary allocation. Tracking pre-baseline requirements prevents surprises when they are formally levied.

Q: Should I note program schedule impacts of technical decisions? A: Systems engineers are responsible for understanding schedule implications of design decisions. Note your assessment of schedule impact so program managers can make fully informed decisions.

Related Reading

• How test engineers use iPhone notes for verification activities
• How process engineers use iPhone notes for manufacturing planning
• How software engineers use iPhone notes for architecture decisions
• How researchers use iPhone notes for complex project management

Sources

• INCOSE Systems Engineering Handbook, 5th Edition
• NASA Systems Engineering Handbook (SP-2016-6105 Rev2)
• ISO/IEC/IEEE 15288, Systems and Software Engineering — System Life Cycle Processes