KSat Story: Elevating CubeSat Requirements Management with ReqView and Capella

 Mar 9, 2026 Denis Oswald stories share

KSat team shares their story of moving from Excel-based requirements management to MBSE workflow integrating ReqView and Capella.

About the Author

Denis Oswald, the storyteller, is an Aerospace Engineering student at the University of Stuttgart, Germany, serving as a Systems Engineer for the project. Having joined the team two years ago at the beginning of the project with no prior experience in satellite development, he quickly discovered his passion for satellite technology and system engineering.

Mission of SOURCE-2 KSat Project

Constructing a satellite is a significant undertaking, and executing such a project alongside university studies introduces additional challenges. For context, a “CubeSat” is a type of miniaturized satellite built using standard cubic units (each 10x10x10 cm). SOURCE-2 (Stuttgart Operated University Research CubeSat for Evaluation and Education 2) is a 6U+ CubeSat, meaning it consists of six of these units, making it roughly the size of a large shoebox. At the University of Stuttgart, this project currently brings together more than 40 students and 5 PhD researchers to design and build this ambitious spacecraft. Developed collaboratively by the Student Small Satellite Association of the University of Stuttgart (KSat e.V.) and the Institute of Space Systems (IRS), the project builds upon a proud educational legacy that has already provided hands-on aerospace experience to over 400 past students.

However, SOURCE-2 is far more than just an educational exercise; it is a cutting-edge technology demonstrator dedicated to sustainable space activities. The mission's primary objective is to test critical technologies for future On-Orbit Servicing (OOS) and Active Debris Removal (ADR) missions. To achieve this, the satellite carries several self-developed payloads alongside experiments from partner institutions. These include the PETRUS-5J pulsed electric thruster for orbit maneuvering, the DETEKT marker-tracking experiment for vision-based navigation, and novel wearless ferrofluidic reaction wheels (Ferrowheels) for attitude control.

Additionally, the satellite will test a high-speed Data Downlink System (DDS), the CorePCB Light, and a Spider Silk experiment to observe how natural silk degrades in the harsh vacuum and radiation of space. These payloads are made possible through collaborations with other universities and student groups, including SeeSat e.V., Hochschule Aalen, and an international partnership with Swinburne University of Technology in Australia.

Despite being a “student” project, the sheer complexity of integrating multiple payloads demands rigorous, Systems Engineering. In the aerospace industry, projects follow strict development phases, starting from early feasibility and conceptualization (known as Phase 0/A) before eventually moving into detailed design, manufacturing, and launch.

Challenge: Spreadsheet Approach & Limits

Requirements form the foundation of any satellite project. However, engineering students eager to design hardware often view Requirements Engineering as a tedious administrative burden. During the initial phases of SOURCE-2, the project's toolset reflected this perspective. The team relied on a massive, shared cloud spreadsheet containing around 250 requirements. This list was a disorganized combination of constraints inherited from past projects and newly drafted, frequently vague criteria. Because attributes, rationales, and parent-child trace links were managed manually, the system was inherently fragile.

As the project grew, this setup quickly fractured. To avoid overwriting data, subsystem teams began downloading and creating their own parallel, localized versions of the spreadsheet. Almost immediately, the single source of truth was compromised. Teams were designing in complete isolation, exclusively monitoring their specific requirements without cross-checking how local changes impacted the overall satellite architecture.

This decentralized approach severely compromised project traceability. If a system-level parameter changed, there was no automated flag to warn subsystem engineers that the dependent requirement was outdated. Verifying whether links were valid in both directions became a heavily manual task, and generating a proper visual requirements tree required writing custom Python scripts. Consequently, the Systems Engineering team lost its high-level overview. Providing meaningful feedback, spotting redundant requirements, or identifying broken links became a monumental, error-prone task. The spreadsheet devolved into an intimidating wall of text that team members actively avoided maintaining.

The decisive point finally arrived from two directions:

• MBSE Approach: As the project planned to transition the architecture design to Model-Based Systems Engineering (MBSE), the spreadsheet became a significant technical incompatibility. MBSE replaces traditional, disconnected text documents with a centralized, visual “single source of truth” model for the satellite's physical and functional architecture. This methodology has become the standard in industrial projects. In an educational context with high student turnover, this visual model is crucial for helping all team members understand subsystem relations and preventing knowledge loss. Integrating requirements into this model requires converting them into a Requirements Interchange Format (ReqIF) format to link them to corresponding architecture elements. Exporting spreadsheet-based data into the ReqIF format required custom-built Python scripts.

• Documentation Overhead: Preparing the documentation for the Mission Design Review (MDR) at the end of Phase 0 involved significant work. The team spent a lot of time manually copying data from the spreadsheet to construct TeX tables with IDs, requirements, and rationales. This constituted an avoidable drain on resources that should have been allocated to actual engineering tasks.

Solution: Enter ReqView + Eclipse Capella

In a student project characterized by high member turnover, adopting new software or workflows introduces risk. If a tool presents a too high learning curve or lacks apparent utility, students tend to ignore it and revert to previous methods. Therefore, an intuitive Requirements Management Tool (RMT) featuring Git version control] and seamless documentation & ReqIF export capabilities was required, without the overhead of an all-in-one project management software.

The open-source software Eclipse Capella^TM was selected as the MBSE tool due to the absence of licensing costs, the abundance of available literature and examples, and its widespread adoption by both industry and other university CubeSat projects.

While Capella excels at designing system architecture, it is not a dedicated Requirements Management Tool. A harmonious integration of both systems was necessary. This synergy was achieved by leveraging the specific strengths of each tool: ReqView acts as the master single source of truth for all textual requirements, while Capella maintains the source of truth for the system architecture.

In Practice: Requirements Rework Workflow

During preparation for the Preliminary Requirements Review (PRR) at the end of Phase A, a critical issue emerged: the spreadsheet-era requirements were insufficiently mature for the project's state. The requirements lacked SMART (Specific, Measurable, Achievable, Relevant, Time-bound) phrasing and no longer functioned as true design drivers. We realized that a rework of all requirements was strictly necessary before continuing with the CubeSat development to avoid future problems when verifying or building an inadequate system.

With ReqView integrated, the rework was structured in 3 distinct steps:

1. Top-Layer Rework: Initial focus was entirely dedicated to solidifying the top layer: mission objectives, strict regulatory constraints (such as space debris mitigation regulations), and the standard CubeSat Design Specifications (CDS). This was done by the system engineers and project managers. Visualizing the requirements with the tree structure proved highly effective for comprehending the true magnitude of the system and made it easy to find where improvement was needed. More importantly, it facilitated the immediate identification of “orphaned” requirements lacking a parent link and highlighted redundant requirements that could be safely deleted.

2. Subsystem Rollout: Once the top layer was at a good stage, the subsystem team could take over and work within these newly defined boundaries. By this point, Systems Engineers had gained sufficient experience with ReqView and requirements writing to actively help the subsystem teams. To maintain alignment, the Capella requirements tree is updated regularly. This allows subsystem engineers to easily review the requirements of adjacent subsystems, identify inter-dependencies, and trigger necessary cross-team discussions. During this phase, ReqView's discussion window and annotations in the tree were utilized by the Systems Engineering team to provide direct feedback.

3. Verification Loop: After the requirement texts and rationales were solidified, the team focused on adding verification details and methods. Future project phases involve adding custom attributes in ReqView specifically for tracking the current status of these verification tasks, ensuring alignment as the project transitions toward hardware testing.

Team Experience & Adoption

For the Systems Engineering and Project Management teams, the transition yielded substantial benefits. Comprehensive visibility was finally achieved. ReqView's customizable dashboards and filters provided metrics of the requirement state, offering a clear overview of the project's status at a glance. Additionally, automated document generation significantly reduced documentation overhead while simultaneously providing a more complete and consistent requirements document. With the built-in Git commit comparison and the requirement history window, tracking changes became more transparent, allowing the team to easily trace how a requirement evolved and identify the author of the modification.

Initial reactions of the remaining team reflected a desire to maintain the status quo and remain within familiar spreadsheet software. The paradigm shifted significantly once the team began actively utilizing ReqView. It became quickly apparent that hiding unnecessary attributes and filtering relevant requirements resulted in a much cleaner, less overwhelming interface than the bloated master spreadsheet.

Also, since all team members were operating from a unified source of truth instead of their separate spreadsheets, subsystems were compelled to actively communicate with one another to resolve inter-dependencies, thereby ending the era of designing in complete isolation.

Payload teams are now required to clearly define their objectives, including performance goals, as formal requirements. This establishes strict, unambiguous boundaries for the platform design, guaranteeing that the platform can physically support the demands of the payloads.

Conclusion & Key Takeaways

The transition to ReqView and Capella fundamentally de-risked the SOURCE-2 project. By abandoning unstructured spreadsheets, unspecific and unmeasurable requirements were successfully purged and replaced with SMART objectives.

Consequently, the Project Management team and external reviewers gained complete confidence in the unified development state. The rework process also successfully uncovered critical missing elements, such as specific regulatory constraints, that had previously been overlooked. Based on the experience of this project, the key lessons learned include:

• Solid Upper Layer First: Payload and mission objectives must be strictly defined before platform design. The fundamental question must be addressed: “What are the exact payload or mission objectives, and how will success be measured?” Designing a functional platform is impossible without a precise understanding of the parameters it must support.
• Maintain Top-Down Discipline: Requirements should not be generated simply to populate a list. A lack of top-down discipline leads to non-SMART requirements. Instead, main constraints, such as objectives, regulations, and applicable standards, must be thoroughly defined before detailing how the platform will comply.
• Define Constraints, Not Solutions: Technical solutions shall not be written into the requirement itself; a requirement should only dictate operational, functional, and performance constraints. This ensures that alternative viable solutions are not prematurely excluded.
• Justification is Mandatory: Proper rationales must accompany every requirement. If the necessity or origin of a requirement (or a specific value within it) cannot be explained, the requirement itself is inherently flawed. Documenting rationales is critical during the verification phase; without understanding why a requirement exists, teams risk verifying outdated criteria or mistakenly deleting vital constraints.

Future Outlook

Currently, the established, clean baseline is being utilized to prepare for the upcoming System Requirements Review (SRR). Subsequent steps in ReqView involve enhancing the verification tracking system and including management of risks.

Learn More

• Source-2: Stuttgart Operated University Research CubeSat for Evaluation and Education 2