OpenSESA

OpenSESA is an open-source, Django-based systems engineering platform for managing requirements, architecture, interfaces, verification, validation, safety assurance, analysis, and project governance in one integrated workspace.

The project is designed for teams that need practical traceability across engineering artifacts: requirements connect to interfaces, baselines, architecture, evidence, verification results, assurance arguments, and delivery governance.

Table of Contents

• What OpenSESA Provides
• Screenshots
• Project Status
• Application Model
• Core Workflows
• Module Map
• Repository Layout
• Running OpenSESA
• Documentation
• Deployment Stack
• Security Notes
• Contributing
• License

What OpenSESA Provides

• Requirements management with structured metadata, review workflows, trace links, import/export support, and coverage views.
• Interface management, including N2 matrix views and project delivery interface filtering.
• System definition and system architecture management.
• Scope, portfolio, operations, and project governance modules.
• Verification and validation planning, case, set, defect, report, and snapshot workflows.
• Baseline, release, and evidence pack management.
• Safety assurance workflows, including hazard views, GSN argument models, GSN diagrams, and baseline comparison support.
• Analysis workflows and quality checks.
• Multi-factor authentication support and configurable security controls.
• Docker-first local development and deployment workflows.
• MkDocs-based documentation for users, developers, operators, and maintainers.

Screenshots

Project Status

OpenSESA is under active development. The codebase is suitable for exploration, contribution, and self-hosted evaluation, but production use should include your own security review, backup strategy, deployment hardening, and operational monitoring.

Application Model

OpenSESA is organized around engineering artifacts and the relationships between them. The application is intended to help teams move from isolated registers and spreadsheets toward a governed workspace where each artifact can be reviewed, baselined, linked, and assessed.

Primary concepts include:

Concept	Role in OpenSESA
Requirements	Capture, classify, review, import, export, and trace obligations or system needs.
System elements	Represent the system breakdown used for allocation, architecture, interface, and verification work.
Interfaces	Define relationships between elements, projects, documents, and delivery responsibilities.
Baselines	Freeze selected engineering state for release, comparison, evidence, and assurance.
Verification assets	Plan verification work, manage cases and sets, record results, and track defects.
Safety and assurance assets	Maintain hazards, GSN-style assurance structures, evidence links, and baseline comparisons.
Portfolio and scope assets	Connect engineering work to projects, phases, delivery organisations, design packages, and scope assignments.

The Django application is server-rendered and backed by PostgreSQL, Redis, and Celery. Docker Compose is the supported runtime path so the application, worker, database, broker, and deployment proxy stay aligned.

Core Workflows

OpenSESA supports engineering workflows that depend on traceable relationships rather than standalone records:

Workflow	What the application supports
Requirements definition and review	Structured requirement records, modules, templates, review comments, imports, exports, quality checks, and coverage analysis.
System definition and architecture	System elements, architecture nodes, decisions, governance records, and relationship views.
Interface control	Interface registers, ICD records, N2 matrices, cross-project interface views, and import/export flows.
Scope and delivery allocation	Work packages, design packages, scope assignments, delivery organisations, allocation views, and dashboard summaries.
Verification and validation	Verification plans, cases, case sets, activities, execution results, snapshots, defects, and RVTM reporting.
Baseline and release assurance	Baseline records, baseline items, evidence packs, release comparison, and assurance-oriented evidence tracking.
Safety assurance	Hazard-oriented views, GSN diagrams, safety argument records, and baseline comparison support.
Impact and analysis	Change impact assessment, gap analysis, quality analysis, and traceability reports.

Module Map

Area	Django apps
Platform foundations	core
Portfolio and project setup	portfolio_mgmt, ops_mgmt
Requirements and traceability	requirements_mgmt, analysis_mgmt, impact_assessment
System definition and architecture	sysdef_mgmt, sysarch_mgmt, diagrams_mgmt
Interfaces	interface_mgmt, project_interface_mgmt
Scope and delivery	scope_mgmt
Verification and validation	verification_validation_mgmt
Baseline and assurance	baseline_mgmt, safety_assurance

Repository Layout

.
├── app/                         Django project root
│   ├── app/                     Django settings, URLs, ASGI, WSGI
│   ├── core/                    Shared UI, utilities, auth helpers, common services
│   ├── requirements_mgmt/       Requirements workflows
│   ├── interface_mgmt/          Interface workflows and N2 matrix views
│   ├── project_interface_mgmt/  Project delivery interface workflows
│   ├── sysdef_mgmt/             System definition workflows
│   ├── sysarch_mgmt/            System architecture workflows
│   ├── scope_mgmt/              Scope workflows
│   ├── baseline_mgmt/           Baselines, releases, and evidence packs
│   ├── verification_validation_mgmt/
│   ├── safety_assurance/        Safety assurance, hazards, GSN, and diagrams
│   ├── analysis_mgmt/           Analysis workflows
│   ├── diagrams_mgmt/           Diagram-related workflows
│   ├── ops_mgmt/                Operations management workflows
│   └── portfolio_mgmt/          Portfolio and project setup workflows
├── docs/                        MkDocs documentation site
├── images/                      README screenshots and repository visuals
├── proxy/                       NGINX deployment proxy image and templates
├── scripts/                     Utility scripts for tests, backups, and vendor checks
├── docker-compose.yml           Local development stack
├── docker-compose-deploy.yml    Deployment-style stack
├── Dockerfile                   Django/Celery image
├── requirements.txt             Python dependencies
└── .env.example                 Environment variable template

Running OpenSESA

OpenSESA is expected to run as a composed application stack:

Service	Application responsibility
app	Django web application, server-rendered UI, API endpoints, migrations, and management commands.
db	PostgreSQL persistence for engineering records and trace links.
redis	Broker/result backend for asynchronous work.
celery	Background processing for jobs that should not block the web request cycle.

Create an environment file from the committed template:

cp .env.example .env

Review application-sensitive settings before starting the stack:

• DB_PASS
• DJANGO_SECRET_KEY
• DJANGO_ALLOWED_HOSTS
• CSRF_TRUSTED_ORIGINS
• email settings, if account emails or password resets are enabled
• MFA enforcement settings for staff, superusers, or all users

Start the local stack:

docker compose up -d --build

Open the application:

http://localhost:8001

Operational checks should also run through Docker Compose:

docker compose run --rm app python manage.py check
docker compose run --rm app python manage.py migrate
docker compose ps
docker compose logs -f app
docker compose logs -f celery

The local app service waits for the database and runs migrations before starting the development server. Avoid running Django commands directly against host Python unless you are deliberately debugging outside the supported stack.

Configuration Focus

OpenSESA reads configuration from environment variables. The settings most likely to affect application behavior are:

Variable	Purpose
DB_NAME	PostgreSQL database name
DB_USER	PostgreSQL username
DB_PASS	PostgreSQL password
DJANGO_SECRET_KEY	Django signing and cryptographic secret
DJANGO_ALLOWED_HOSTS	Comma-separated Django host allow-list
CSRF_TRUSTED_ORIGINS	Trusted origins for CSRF-protected requests
EMAIL_HOST	SMTP server hostname
EMAIL_PORT	SMTP port
EMAIL_HOST_USER	SMTP username
EMAIL_HOST_PASSWORD	SMTP password
DEFAULT_FROM_EMAIL	Default sender address
CELERY_BROKER_URL	Celery broker URL
CELERY_RESULT_BACKEND	Celery result backend URL
MFA_TOTP_ISSUER	Issuer label for MFA authenticator apps
MFA_TRUST_ENABLED	Enables trusted-device MFA behavior
MFA_ENFORCE_FOR_STAFF	Requires MFA for staff users
MFA_ENFORCE_FOR_SUPERUSERS	Requires MFA for superusers
MFA_ENFORCE_FOR_ALL_USERS	Requires MFA for all users

Generate a strong Django secret key before using the app beyond local experimentation:

docker compose run --rm app python manage.py generate_secret_key

Application Checks

Use the test suite to validate application behavior across the domain modules:

docker compose run --rm app python manage.py test
docker compose run --rm app sh -c "DJANGO_SETTINGS_MODULE=app.settings_test PYTHONPATH=. pytest -v"
docker compose run --rm app sh -c "DJANGO_SETTINGS_MODULE=app.settings_test PYTHONPATH=. pytest app/requirements_mgmt/tests/test_views.py -v"
docker compose run --rm app sh -c "DJANGO_SETTINGS_MODULE=app.settings_test PYTHONPATH=. pytest --cov=app --cov-report=term-missing"

Linting and Checks

Run Django checks:

docker compose run --rm app python manage.py check

Run lint checks:

docker compose run --rm app python -m flake8

Run type checks:

docker compose run --rm app python -m mypy

Documentation

The documentation site lives under docs/.

Key sections include:

• User guide
• Development workflow
• API overview and examples
• Architecture notes
• Operations runbooks
• Quality gates and review material

The Markdown source is committed under docs/docs/. If you add an MkDocs configuration file for your deployment, build it through Docker Compose so the documentation environment remains reproducible.

Deployment Stack

docker-compose-deploy.yml provides a deployment-style stack with:

• Django/uWSGI app container
• Celery worker
• PostgreSQL
• Redis
• NGINX proxy

Start the deployment stack:

docker compose -f docker-compose-deploy.yml up -d --build

Run migrations:

docker compose -f docker-compose-deploy.yml run --rm app_opensesa python manage.py migrate

Collect static assets:

docker compose -f docker-compose-deploy.yml run --rm app_opensesa python manage.py collectstatic --noinput

View logs:

docker compose -f docker-compose-deploy.yml logs -f app_opensesa proxy_opensesa celery_opensesa

Production deployments should use real secret management, TLS termination, database backups, monitoring, log retention, and a reviewed host/CSRF configuration.

Data, Backups, and Local Artifacts

Do not commit local runtime data or generated artifacts. The repository ignores common local-only files, including:

• .env and .env.*
• SQLite and local database files
• coverage outputs
• cache directories
• backup dumps
• private keys and credential files

Backup and recovery helper scripts live in scripts/, but backup outputs should remain outside version control.

Security Notes

• Never commit real secrets, private keys, production .env files, database dumps, or customer/project-sensitive exports.
• Rotate any credential that may have been exposed before publishing or sharing a repository.
• Use a unique DJANGO_SECRET_KEY for every deployed environment.
• Keep DEBUG=0 outside local development.
• Set DJANGO_ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS explicitly.
• Review MFA enforcement settings before onboarding users.
• Review email backend settings before enabling account emails or password resets.
• Run dependency and container scans as part of your own release process.

To report a security issue, avoid opening a public issue with exploit details. Contact the maintainers privately through the repository owner or your established project channel.

Development Guidelines

Domain apps should follow the established Django layout:

• models.py: ORM models only
• views/: view modules split by responsibility
• urls.py: route mapping only
• forms.py, filters.py, tables.py, resources.py: app-level web/data concerns
• services/: business/domain logic that should not live in views
• templates/<app_name>/...: app templates
• tests/: feature-focused tests
• management/commands/: app-specific commands when needed

Import boundaries:

• Domain apps may depend on core.
• Domain apps should not import peer app internals.
• Shared cross-app behavior should live in core or an explicit shared service module.

Testing conventions:

• Keep tests under app/<domain>_mgmt/tests/ or the relevant domain app test directory.
• Use file names prefixed with test_.
• Prefer small, focused test modules.
• Use pytest with app.settings_test for targeted test execution.

Contributing

Contributions are welcome.

Recommended workflow:

1. Create a feature branch from main.
2. Keep changes focused and documented.
3. Add or update tests for behavioral changes.
4. Run checks through Docker Compose.
5. Update documentation in the same change set when behavior or setup changes.
6. Open a pull request with a concise summary, testing notes, and any migration or deployment considerations.

Before opening a pull request, run:

docker compose run --rm app python manage.py check
docker compose run --rm app sh -c "DJANGO_SETTINGS_MODULE=app.settings_test PYTHONPATH=. pytest"

License

OpenSESA is released under the GNU Affero General Public License v3.0. See LICENSE for details.