Design: Requirements

Our requirements documents was a living document that changed as the project went on in response to the data we received. At the end it was nearly two-hundred items long, describing what features a handheld for NASA problem reporting should support and how they should be implemented. Our own device implemented all of these requirements as was possible in the project span, and the features that we could not implement we gave to NASA as recommendations.

First Iteration of Requirements

While completing the consolidation of our contextual models, we began to list initial, obvious design requirements. These minimally extrapolated from the current reality, and should be considered more a reaction than design initiative. We continued to develop and specify these requirements as we explored various design concepts.

The majority of these early requirements were simple and obvious means of tolerating NASA's technical environment, including such concerns as durability and the danger of fragmentation in clean areas (the protective process against various types of breakage is known as ÒhardeningÓ) as well as battery-life capable of surviving a full shift, and usability in dark or confined spaces with spotty wireless connectivity.

The real meat of this first iteration of requirements can be found under the requirements for the enhancement of the running addendum (the process that brings problems to the attention of engineers) and the reduction of typographical errors. These requirements would disappear later on, to be developed into greater maturity in the next iteration.

First Iteration of Requirements

While completing the consolidation of our contextual models, we began to list initial, obvious design requirements. These minimally extrapolated from the current reality, and should be considered more a reaction than design initiative. We continued to develop and specify these requirements as we explored various design concepts.

The majority of these early requirements were simple and obvious means of tolerating NASA's technical environment, including such concerns as durability and the danger of fragmentation in clean areas (the protective process against various types of breakage is known as ÒhardeningÓ) as well as battery-life capable of surviving a full shift, and usability in dark or confined spaces with spotty wireless connectivity.

Second Iteration of requirements

Our second iteration of requirements included a specific demand for photography and possibly even richer media, the facilitation of easy creation of readily searchable reports to allow engineers easy access to trends in archived PRs while still reducing the burden of paperwork upon the technicians, and increased levels of satisfaction, efficiency, and quality of work. As the self-respect of technicians and their place in the local pecking order depends on high quality of work, all three of the latter are subtly related.

third Iteration of requirements

Before jumping headlong into the prototyping phase of our project, we decided that it was important for the group to have a unified vision of what it was that was going to be produced. As such, we revisited the data we had been compiling for over a semester, the potential form factors we had analyzed, and the various workflows that we had conceived, and began to narrow down all of these amorphous ideas towards a more well-defined design. We began the process of building this requirements document with a very large affinity diagram. We spent two days debating conflicting ideas of functionality, rewording specifications, and deciding which ideas needed to be user tested before being approved for inclusion in the prototype. The results became the third iteration of our requirements document.

final refinement of requirements

We were now ready to move to a final prototype for rapid iteration. Before we could do so, we met to refine our requirements towards the end goal of our project: a functional and compelling demonstration of our design. We finalized what requirements were to be implemented in our device, recommended to NASA but not implemented due to time restrictions, and what would be partially implemented. The most major decisions were to fully support all rich media, recommend but not support work authorization document support, and to clarify how problem report changes, duplicates, and threads would be handled. This we described in detail in our final report to NASA.