Design
SCN-01 · Operating conditions
Consider the app, service and physical controller together. Use the scenario and system boundary to examine behavior when connectivity changes.
Systems engineering for engineers and AI agents
Define the system. Build on shared understanding.
Describe what the system must do, how it will be used, and the constraints it must respect. Connect that knowledge to requirements so engineers and AI agents can use it throughout design, implementation, verification, and change.
Account required to start a project. The example is illustrative.
DefineConnectReviewUse throughout engineering
Remote door access
Select an item to inspect its meaning.
- Explored in
- Informs
- Supported by
SW-01 · Software requirement
The app shall display Unlocked only after receiving the controller’s physical unlocked-state confirmation correlated to the current request.
A closer look
Watch the introduction.
A brief introduction to Ellygent. Explore the connected system example at your own pace when you are ready.
Explore the system example →One system, connected knowledge
Define purpose, operation and behavior.
Ellygent is a systems engineering workspace for defining and maintaining connected engineering knowledge. In this example, requirements stay connected to purpose, operating conditions and boundaries.
Purpose and people
Authorized residents need remote access. Residents and access administrators have different responsibilities and expectations.
Operation and boundaries
A request crosses the app, service and door controller. Connectivity can fail. Mechanical access and emergency egress sit outside this example.
Behavior and open decisions
Physical confirmation informs the displayed outcome. Offline behavior remains a recorded question until engineers review and resolve it.
From definition into engineering work
The same understanding carries forward.
Engineers and AI agents can use selected engineering knowledge throughout the work. Ellygent maintains the information that supports these activities; it does not perform them all.
Implementation
SW-01 → SYS-01 · Requirement source
Engineers and AI agents can work from the software requirement and its system-level reason: accepting a command does not confirm that the door unlocked.
Verification
OBJ-01 + SYS-01 · Expected outcome
Use the expected physical outcome and operating conditions to inform verification work. Check the app’s reported outcome against controller confirmation.
Change
DEC-03 · Related information
If offline behavior changes, follow maintained relationships and source notes to investigate the scenarios and requirements that need review.
Inside Ellygent
Develop the definition. Keep it connected.
Author and connect
Develop purpose, objectives, stakeholders, scenarios, boundaries and constraints alongside requirements. Record rationale and questions as understanding develops.
Use AI assistance with review
Request proposals and quality feedback inside Ellygent. Inspect the reasoning, edit the content and decide which changes to accept.
Keep a reviewable record
Discuss requirements with linked comments, inspect traceability and inspect saved project versions. Revisit decisions as the system evolves.
For engineers and agents downstream
Read it here. Take the relevant information with you.
Choose the scope and version, inspect the exported information, then supply it to your engineering workflow or AI agent. Refresh your copy when the definition changes.
Explore export, CLI and API workflows →01
Read and inspect
Use the engineering Viewer, relationships and traceability matrix to review recorded information in Ellygent.
02
Download selected content
Share a definition summary or specification export. ReqIF supports requirements exchange; readable exports support review. A summary does not include every requirement and relationship.
03
Query or pull a context package
The Context API and CLI provide selected definition content, requirements and relationships. The package manifest identifies its project, version and export time.
You choose which files or API results to supply to external tools. Their output still needs engineering review.
Engineering depth, where needed.
ReqIF exchange · Saved version snapshots · Requirements quality reviews · Functional Safety analysis
See capabilities and their scope →Safety tools support engineering analysis; they do not establish certification.A clear way to evaluate.
Explore the public example first. Then create an account, complete activation where required, and test one small definition with your own non-sensitive content.
Read practical questions and access conditions →Start with the system you are working on
Give your engineering work a connected foundation.
Bring what you know. Record what is still open. Develop the understanding as your system evolves.