The homepage serves as a central hub for discipline engineers to access the requirements they need. The page showcases an engineer’s owned requirements and the usage contexts, verification documents, and rationale of each attached team.

Dedicated to a specific requirement, engineers can see the verification activities other teams have chosen and why, as well as quick view of how data flows across documents and how teams are related to one another. This reminds engineers that their work is a part of a larger system, and it takes collaboration across teams to complete the “bigger picture.”

Designated discussion spaces on each discipline teams’ provides a public space for aligning design assumptions. We created this discussion feature to encourage cross-team communication early and often to catch discrepancies prior to milestone reviews. Integrating conversation facilitating functionality in the data context creates a structure for capturing decision points, solving the problem of lost data.

When a decision has been reached on a discussion post, the original poster can mark a resolution point from any of the post comments. This resolution will be pushed to the top of the post thread as a highlight, alongside the originating post, creating a reference point for other users trying to understand the conversation around the usage context.

When a chat conversation can’t capture sufficient granularity or offer the privacy needed for sensitive data, Requests for Information (RFIs) fill the need. RFIs allow engineers to more formally request documentation or information outside the scope of a casual comment. RFIs can later be archived and referenced to inform future designs.

NASA makes history, and history makes NASA. Discipline engineers often use past decision-making to help guide their current designs. Historical references can come from decisions made decades ago in past programs, such as Space Shuttle, or just decisions made a few months ago. Regardless, creating a documentation trail of historical decisions is essential. We created the Version History functionality to answer this need and facilitate decision traceability.

A visualization of  the connections between requirements, documents, and teams gives engineers a broad perspective of what’s happening across SLS development. Showing dependencies surfaces critical information that supports engineers in designing integratable subsystems.

An engineer’s needs evolve as the project evolves. Earlier in the program when requirement decisions are in flux, it’s important to understand the larger discipline team ecosystem around you. Later in the program, it’s more important to have an understanding of how models are being used to fulfill documents and what connections are most important.

Helping engineers track where and how team-generated data is being applied across models and reports improves transparency and creates an avenue for additional verification.

In addition to monitoring document connections visually in the Relationship Diagram, engineers can also easily access a list view of document connections. This gives them a clear, consolidated way to understand how the data in their documents is being used. It is extremely important for engineers to track how documents interface with one another to ensure everybody is aligned on design decisions and using each other’s data correctly.