In our company we demand that engineers write a brief one liner section in each ticket they work on (from jira/github/gitlab etc) that explains the "business requirement".. the logic of that is explained here (text copied from our "issue protocol" document verbatim):
Business Value add
The software projects we work on must always ultimately serve a business need. Simply put b/c at the end of the day, someone should be paying for the development of these tasks. Therefore, it's very important to express the value add of the task in a language that non-technical person can understand and appreciate.
Think about it in the following scenario: we bill the client per issue (ie in the monthly invoice we add the issue number and description in a spreadsheet). For the client to know where their money is going, they should be able to read the issue business requirement and immediately understand it. This isn't the job of the PM on the project, this is the job of the engineer working on the issue as they're the one most familiar with it. If you need help expressing the business value of the technical work you're doing, contact your PM and they can give you a hand.
Business Value add instructions
Must be a one liner
don’t write a whole detailed description of the requirement and the reason behind it and the background etc. Simply state the business value of what the task is about.
Must be a parent task
No need to write business requirements for subtasks. The business requirement for the subtasks can be inferred from the parent task
Must explain the business value add, not just describe a problem
People don’t pay engineers to report a problem. They pay them to fix it. That’s why the business value add section should simply state the value added by doing it.
Bad example Users won't be able to successfully checkout using valid credit cards.
Good Example Fix bug preventing using from successfully checking out by using valid credit cards
Must use the imperative mood
This is best explained here. Similar to the git commit messages, business value should be written in imperative mood, which is “spoken or written as if giving a command or instruction”. A few examples: Clean your room Close the door Take out the trash Please see above link for more thorough explanation
I have used this policy with several teams/startups with mixed results. But I was going over the book Software Requirements and it showed this image:
and it shows "business requirements" as high level business objectives that belong in the vision and scope document, rather than "functional requirements specification" doc.
Does it make sense to ask engineers to put a Business Value Add section in each issue they work on? Let's assume that engineers aren't trained for that kind of documentation (from my own experience, it's a hit or miss chance that engineers will be able to properly write a business requirement section, most of the time they do it just as getting through the motions and they don't really do a good job) then the next question is: does it make sense for anyone to write a business requirement section for each issue.. be it a BA or a PM etc?
I just wanted to clarify something. Basically I guess my question makes more sense if given the context that the engineers doing the work are not from the same organization that's paying for the work. Classic example: entrepreneur outsources software work to a software shop, and pays them. The question I get all the time from such entrepreneurs is: where is all my money going? By requiring that the outsourcing company fill in the business value add section (and this is why it doesn't have to be an engineer doing it.. it could be the PM/BA from the outsourcing company), then the client gets a lot more visibility on where they're money is going, and I think that's fair (it better be, the client can simply make that a requirement when signing the contract).