3 ms·
I think it's important to keep requirements in Git along with the source code. That way when you implement a new feature you can update the requirements and com
by adrianmsmith 4y ago
I think it's important to keep requirements in Git along with the source code. That way when you implement a new feature you can update the requirements and commit it along with the code changes. When the PR is merged, code and requirements both get merged (no chance to forget to update e.g. a Confluence document). Each branch you check out is going to have the requirements that the code in that branch is supposed to implement.
For simple microservice-type projects I've found a .md file, or even mentioning the requirements in the main README.md to be sufficient.
I think it's important to track requirements over the lifetime of the project. Otherwise you'll find devs flip-flopping between different solutions. E.g. in a recent project we were using an open-source messaging system but it wasn't working for us so we moved to a cloud solution. I noted in the requirements that we wanted a reliable system, and cost and cloud-independence wasn't an important requirement. Otherwise, in two years if I'm gone and a new dev comes on board, they might ask "why are we using proprietary tools for this, why don't we use open source" and spend time refactoring it. Then two years later when they're gone a new dev comes along "this isn't working well, why aren't we using cloud native tools here"....
Also important to add things that aren't requirements, so that you can understand the tradeoffs made in the software. (In the above case, for example, cost wasn't a big factor, which will help future devs understand "why didn't they go for a cheaper solution?")
Also, if there's a bug, is it even a bug? How do you know if you don't know what the system is supposed to do in the first place?
Jira tickets describe individual changes to the system. That's fine for a brand new system. But after the system is 10 years old, you don't want to have to go through all the tickets to work out what the current desired state is.
- asabla 4y agoI really like this idea. However, what would be missing from this is discussions for each requirement specified. Or would you want to include that as well? It would be nice having a dedicated directory for requirements, src, infra, tests and docs. Which would make things easier to track over long period of time I think
- mtoddsmith 4y agoWhat happens when your requirements span multiple projects and repositories and microservices including frontend and backend work etc.? That doesn't all fit into a git PR.
- mike22 4y agoIn the world I live in (big org using Jira), that sounds like an epic, with lots of stories underneath. Some stories are defined early on, more can be added as the business comes up with new reqs or devs find things that need more work.