Outlining Requirements for a Privacy-Focused Web Form

When I first started this course, the client that I am currently working with had presented me with a document detailing a list of features for the project. The project is essentially an anonymous, secure web form for an LGBTQ non-profit that allows users to share their experiences. However, after the meeting with my professor for this course, I had a much better framework for effectively approaching the design of an MVP during the 12-week sprint. This blog post will explain the thought process behind choosing the functional and non-functional requirements that are needed for the MVP.

Structuring Requirements

Not all requirements are created equal, and organizing requirements based on different tiers proved to be really helpful in keeping the MVP small and manageable and focusing on what was most important. During the meeting, I was introduced to three different priority levels, which equate to “must haves”, “nice to haves”, and “stretch goals”.  As the name suggests, they correspond to requirements that the MVP must have at launch, and if time permits, what requirements would be nice to have, and if there is sufficient time and resources left, the stretch-goal requirements that could be added. A useful analogy I was given was choosing the right rental car based on its features. Of course, an engine is required, but do you really need a radio? Now, consider if it’s a cross-country road trip, now maybe you do! This aligns cleanly with the three tiers we just went over, since an engine is a must-have, and a radio and GPS would be a nice-to-have, but possibly a must-have for a long road trip, and hybrid fuel could be a stretch goal.

Furthermore, requirements can also be divided into functional and non-functional requirements. Functional requirements describe what the product does (its functions), whereas non-functional requirements describe how well it should perform those functions. As an example for the project that I am working on, one functional requirement might be that the web portal allows anonymous and secure submission of data. This is a functional requirement because it outlines a specific feature, focusing on functionality rather than specific implementation. A non-functional requirement that relates to this might be that the web form uses HTTPS to transmit data from the web form to the server. This is a non-functional requirement since it details specifics, such as  a particular encryption scheme, for handling and sending web application data between the client and server. Understanding which features are functional requirements is helpful when planning the overall scope of the project, and outlining the non-functional requirements can be helpful when architecting the actual implementation, such as choosing the correct technological stack.

Requirements Table