Mapping Project Requirements

The Open Source Alliance for Open Scholarship Handbook was created over three days in 2018 and discussed, created, edited, reviewed, and contributed-to, and otherwise extended by contributors. This project is open to contribution and licensed CC-0.

About Requirements

👋 You: You’re ready to get started building your project, or you’ve already started and are now trying to define the path from project idea to project launch. Maybe you’ve got a running list in that big, beautiful brain of yours. Now it’s time to get it out onto paper (or pixels) for all to see.

🤷🏻‍♂️What: A set of project requirements encompasses the features, functions, expectations, must-haves, and nice-to-have elements of a project.

❓Why: Defining project requirements is a good way to check what your project should do and, more importantly, why. Your requirements checklist is your benchmark for where you’ve been, where you are, and where you’re going. It’s important! It can be your north star – your guide in times when you feel like you’ve strayed or are unsure where to go next. This is your chance to map out and evaluate how your project's features embody the meta goals of your project. Sometimes you’ll find that features that seem important to you might not get you closer to meeting your mission. Think of requirements as your insurance -- you can refer back to it when justifying your time, effort, and costs.

⏰ Time: Creating project requirements will take several hours, repeated throughout the course of a project. Every project is dynamic. As projects change, so do the things needed to make them reality. Therefore, defining requirements is an iterative process. You should come back to your requirements throughout the duration of your project to make sure that you’re either: 1) making progress and on track to meet your goals through each feature or component you’ve built, or 2) redefining your project requirements to fit the changing needs, vision, or scope/scale of the project.

What you’ll learn here

This section offers suggestions to help you adapt a set of project requirements that are appropriate to the scale and scope of your project as well as its phase of development. Whether you’re building software and/or hardware, or designing experiments, communities, or events, following a structured process will help you make your ideas a reality.

What we haven’t addressed yet

Below are our to-do's! Motivated to contribute? Email us at [email protected]

• The language of a well-written requirements document
• The structure of a well-composed requirements document
• Examples of requirements documents across domains and contexts
• A glossary of all the terms that are used for the same thing

Scope  and Scale

The methods shown below can all be remixed and reused to define requirements for a variety of scopes and scales. You may adjust the number of requirements or prioritize certain requirements over others in order to do a “proof of concept” or showcase a prototype that makes it easier for people (and yourself) to envision what your thing might look like in real life. By scoping for options like a minimum viable product (MVP) or the full product of your dreams, you can build up your project in a way that is appropriate to your timeframe, resources, and other aspects.

👉 Proof of concept (POC)

A proof of concept is more than a set of wireframes or a click dummy, but less than an MVP. A proof of concept shows that elements of your concept or your concept as a whole have potential.

Proofs of concept can take on varying levels of fidelity. An example of a simple proof of concept is the plan for a new kind of online survey tool. You'll want to show that you’re able to create a website for people to punch in their survey data, set up a database for the data to be sent to and stored, and show how a person might log in to view their survey results. It is certainly not a full system, but it shows that there’s potential.

👉 Minimum viable product - MVP

An MVP is the minimum number of features and fulfilled requirements that would allow your product or project to exist in the wild. It might not have all the bells and whistles or maybe none at all, but it is unique enough and functional enough to show that your product is working and can be used by others.

In the case of our new online survey tool, an example of an MVP would be a website with its own domain name, simple but well-designed user interfaces for form submissions on the front end; data management and organization as an administrator; and a secure database and server code to process and store information about your users and their survey data. You may not have implemented all the fancy features of your dreams or worked out yet how your new survey tool might be HIPPAA compliant or pass IRB for medical subjects, but your product is working and is distinct from other works in the field.

👉 The full product / project of your dreams

It’s not a bad idea to scope features and requirements for the project of your dreams. By mapping out all the things that would bring you and your audience joy, you can get a picture of the full landscape of needs, wants, and desires that will help make your project a household name (or at least people's primary touchpoint in your domain). Going forward without this map in mind can send you into a spiral of doom -- zipping out of control by trying to improve things but instead implementing ideas that may actually make your product worse. That potential for overreach is why it is important to interview and work with your target audience to know what is working and what is not.

Want to think more deeply about requirements? Read on for more from Joey about a tapas method that offers lots of options for each step in determining requirements.