Requirement gathering for ground system and flight dynamic software can be challenging for a development team that are not themselves aerospace engineers. The Earth Science Mission Operation Flight Dynamic Support analyst and development teams worked together to solve this headache.

When working with ground station and flight dynamic software the users, customers, and often requirement gatherers are often aerospace engineers. Their understanding of how the software should function, while complete, is highly specialized. On the other side, the development team writing these tools are, most often, not experts on orbital mechanics. This causes reworks and broken features when the development team attempted to implement a system they do not understand enough.

The dev team began with an Agile software development approach and slowly started folding the analyst team into the process. These teams sought to organize the requirements gathering effort into five key patterns:

1. Training on User Stories – The standard User Story format of “X does Y and gets the results of Z” (i.e. “John clicks on the exit button and the application shuts down.”) is easy for analysts to write and helps the development team extrapolate derived requirements.
2. Static Test Data – Test data that doesn’t change over time (whether it is data captured at a single point in time or fully mocked) allows the development team to better understand complex results by comparing their outputs to a known set of outputs.
3. Ticket Template – Applying a software change request template allowed breaking the data up into sections of background, user stories, expected results, etc. helped organize both teams and segregate date to avoid confusion.
4. Embedded Analysts – The development team keeps an aerospace engineer on staff to assist in the development work that requires specialized aerospace knowledge. Historically, these aerospace engineers transition to & from the analyst team allowing for better knowledge transfer over time.
5. Open Communication – Both the flight dynamic team and the development team strive to attend each other’s meetings, converse with each other outside of work, take each other’s onboarding training, and generally engage with each other as co-workers rather than a client-developer relationship. As the teams stopped seeing each other as adversaries or “the others” they felt more comfortable, started having open communication, and worked closer to resolve misunderstandings.
   

Over the past year and half, the two teams have been able to better coordinate the requirement gathering process. The outcome of this on the development side has been efficiencies gained in development, shorter development cycles, and reduced non-conformities. On the analyst side, testing has become shorter and more of a routine exercise and large projects (such as system upgrades) have gone from something feared and resisted to being requested. Both teams gained a better understanding and appreciation of each other, and it has positively affected all the work both teams do. Ultimately this work minimized the back and forth between the teams maximizing the code quality.