Project Requirements

Documents based on research to determine user stories, technical details, and success criteria for development efforts.

One of the most important genres I write in my leadership position at Eli Review is project requirements. These documents are not public-facing but they serve multiple internal audiences. For any development project, whether adding a new feature or upgrading an existing component, these documents define the scope and purpose of the work both for the instructional group and marketing people who use the product but also serve as a roadmap for developers carrying out the work.

Requirements documents are meant as much for stakeholders as much as developers - in this example, the requirements spell out exactly why this feature needs to be built.

My job is to work with both groups of stakeholders and make sure the purpose and scope of the project are clear. For the teaching team, the document ensures that the new development work will address the use cases it’s intended to. For developers, it lays out the scope of the work in the most granular detail possible without getting overly technical, making it possible to place a reasonable estimate of time and cost on that work.

Here are requirements documents for three different Eli Review development projects:

In the case of course cloning, the requirements document became an important site of inquiry for both instructional designers and developers for several critical components of the work.

In each of these cases, I created the majority of the content and then sought feedback from each party and revised as necessary. As project manager, it’s my job to shepherd materials like this amongst the various constituent groups to make sure we’re on the right page and then lead the implementation of the documented work.