Recently, we had a major feature release, and I’d like to share my thoughts on “non-functional requirements.”
Reference Information on Non-Functional Requirements
First, I think background knowledge about “non-functional requirements” is necessary, so here’s some reference information:
Troubles from Unmet Non-Functional Requirements
Background
Recently, I successfully completed the initial release of a project that took about 5 months. While there were no major troubles after release, the “functional requirements” were met, but it wasn’t in a state where non-engineers could use it - it was in a state where only the minimum functional requirements were satisfied. So for a while, I, as Product Manager and engineer, had to operate it myself. (Unexpected)
As a result, the development team’s operational costs increased, so we had a reflection point that we wanted to release in a state where minimum “non-functional requirements” were met so non-engineers could use it immediately after release.
Solution
After actually using the feature, I create GitHub issues for difficult-to-use points, document improvement proposals, and add them to the Product Backlog.
Once my (Product Manager) feedback work is completed to some extent, I’ll have engineers within the Scrum team also experience the operation and provide self-feedback. By having them do self-feedback, I hope they’ll apply it to future development.
Originally, we should have checked quality at the Sprint Review stage, but we only checked whether “functional requirements” were met during Sprint Review, which is why this problem arose.
That’s all about wanting to meet non-functional requirements properly from the Gemba.