Flutter App: PotatoVerse — Requirements Prioritisation
Picking up from where we left off with our PotatoVerse application, this article will be exploring the next phase of the app development process— requirements & prioritisation. If you missed the last post in this series (or need a quick refresher), read that article on scenarios here.
The final version of the scenarios we created can be used to prioritise the requirements/features for our application.
Requirements prioritisation is the process of identifying, evaluating and ranking the application features based on the business value, customer needs and use cases, technical feasibility and time constraints.
Key benefits of prioritising requirements
- Clear focus: Prioritisation helps the team to understand the most crucial features and align resources and efforts as needed.
- Time to market: Because of time constraints, it is necessary to prioritise the features and requirements to ensure that the most important features are implemented first. This will also shorten the time to market for the product.
- Optimise resources: When focus is on developing high-priority features, the resources (time and effort) get allocated and used effectively. It is important to balance resource constraints with feature importance.
- Scope creep: By prioritising requirements, the team can make informed development decisions and avoid scope creep. Thus, the valuable features get implemented within the above time constraints.
- Customer satisfaction: Prioritising features based on customer needs and use cases ensures that the product’s core functionalities are delivered first which makes the app more likely to meet user expectations. This should be an iterative process based on user feedback even as they continue engaging with the app after it’s been launched in the market.
MoSCoW Prioritisation Technique
There are various techniques that one can use to prioritise their requirements e.g., MoSCoW, Kano model analysis, 100 Dollar Method etc. For our project, we are going to use the MoSCoW method.
The MoSCoW methodology places features and requirements into four distinct categories. That is; MUST haves (M), SHOULD haves (S), COULD haves (C), and WON’T haves (W).
- MUST Have (Mandatory): These are features that are completely critical to the application. They are core features. They must be implemented for the application to be considered functional. If even one “Must Have” feature is missing from the app, the project will be incomplete and will essentially be a failure.
- SHOULD Have (High Priority): These are important features, but their delivery is not time critical in the first version of the application (MVP). Missing a few “Should Have” features doesn’t directly translate to a failure. We can pick a number of such features to implement and schedule others for the next version release.
- COULD Have (Preferable): These are desirable functionalities that improve the usability of the application but are not critical for the current application release. They are “Nice to Have” features and can be considered only if resources allow it.
- WON’T Have (Postponed): These are the least critical functionalities. They won’t be considered in the app releases. Since they are out of scope, they can be archived.
Part 4 — Requirements Prioritisation
From our “user research”, the personas we created and the scenarios, the following are the PotatoVerse features and their MoSCoW prioritisation.
Must Haves
- Recipes: The app must contain a variety of detailed potato recipes that are easy to comprehend
- Search and filtering: Users must be able to search and filter potato recipes based on specific criteria like dietary restrictions (e.g., vegetarian, vegan), cooking time, ingredients they have in their pantry, meal type (e.g., breakfast, lunch, dinner), etc.
- Recipe favourites: Users must have the ability to save or bookmark their favourite recipes so that they can easily access them later.
- Responsive design: The application must be responsive and work well on both mobile and tablet devices catering to our various user personas.
Should Haves
- Settings and preferences: The application should allow users to create and manage settings and preferences e.g., history, set app themes, set notifications, reminders, etc. All personas will benefit from a personalised system profile.
- Recipe ratings and reviews: Users should be able to rate recipes and leave reviews to help other users to also decide which recipes to try.
- Shopping list integration: Users should be able to add ingredients from recipes to a shopping list that they can easily manage and access when they go to the grocery store.
- Video tutorials: Recipes that are a bit complicated should have video tutorials that show the step-by-step cooking process. Our personas can benefit from video instructions/guidance to ensure they are following the recipe correctly.
- Nutritional information display: The app should display detailed nutritional information for each recipe. This is beneficial for health-conscious users who need to ensure their dishes meet certain standards.
Could Haves
- Social media sharing: Users could share the recipes they like directly to their social media accounts.
- Meal prepping: Users could plan meals for the week which incorporate potato recipes. The generated shopping list could trigger a notification corresponding with their shopping days to remind them to buy the groceries thus saving time.
- Ingredient substitutes and tips: The app could suggest ingredient substitutions for users with dietary restrictions or preferences.
- User recipe submission: Users could be able to submit their own potato recipes to the app, possibly for community or public viewing.
Won’t Haves
- Artificial intelligence and Augmented reality assistance: An AI and AR feature that provides real-time cooking assistance and tips while users are preparing their meals could be beneficial for all personas, but it’s not essential and could be costly to implement (time wise and research wise).
By classifying our PotatoVerse app features using the MoSCoW methodology, the team can prioritise and develop the most critical aspects of the app for the first/initial release. The less critical features can then be kept in mind for future enhancements, updates, and versions. This will avoid scope creep and ensure timely product launch.
In our next article in this series, we’ll be getting into the application design starting with the sitemap. Stay tuned for that!
“My idea of heaven is a great big baked potato and someone to share it with.”
— Oprah Winfrey
I hope you’ve found this article interesting and are still engaged with our potato app.
Thank you for reading ❤
Check out the previous articles on this project.
References
1. https://fibery.io/blog/product-management/requirements-prioritization-techniques
2. https://www.prodeology.com/blog/a-product-managers-guide-to-priority-scoring
3. https://techcanvass.com/blogs/requirement-prioritization-techniques.aspx
4. https://www.linkedin.com/pulse/requirement-prioritization-angel-newportright/
