4 ms·

Great read, I spent years thinking requirements should live somewhere like Jira, and I feel for many teams this is the case. But as the author mentions, Jira c

Great read, I spent years thinking requirements should live somewhere like Jira, and I feel for many teams this is the case. But as the author mentions, Jira contains tasks related to bugs, text changes, colour changes etc.. These are not product requirements per se. Like the author, I came to the conclusion requirements are best kept in a requirements management system, that integrates with your project management tools - a source of truth and living documentation about what the product does. (Not conversations back-and-fourth about bugs and UI minutia). And like the author, I have also created a requirements management system https://userdoc.fyi https://userdoc.fyi (currently we are specifically focused on user stories, personas, and journeys).

GrumpyNl 3y ago
You can easily create requirements in Jira.
- chrisrickard 3y ago
  Correct, you can create requirements anywhere, I just feel requirements are more important, and long-lived than a transitory Jira ticket. E.g. A Jira ticket moves to "Done", the requirement is complete, and people are happy. But the important info on that ticket has essentially disappeared - obviously you can mine your thousands of tickets for historical info - but no one really does.. as it's mixed with bugs, changes, improvements, conversations etc.
- okl 3y ago
  I don't know how exactly you'd do that and depending on the project it might be fine. One important feature of a requirements tool is that it allows you to "tag" a set/document of requirements with a version that corresponds to your released artifacts and create "diffs" between such versions. I don't think that's possible with plain Jira(?)
dhx 3y ago
I like the personas and journey features. In formal systems engineering, a common mistake (including for the 737MAX[1]) is failing to model system users, and treating system users as completely external and separate to what is being designed. I'd love to play with an Inform 7[2] like language for capturing "operational scenarios"[3] (systems engineering jargon for roughly a combination of "personas" and "journeys"). In many fields of systems engineering (e.g. aviation), vocabulary has to be tightly controlled and syntactically unambiguous language used. As is the case with Userdoc, an LLM could propose operational scenarios, but they'd need to be converted to a syntactically unambiguous language, and be vetted by humans. Of current approaches to formally capturing operational scenarios, and I don't think any of these do a particularly good job of it, I prefer Object Process Methodology[4] (text representation only) over SysMLv2[5] (again text representation only, and this is R&D/draft). I'd only mention SysMLv1 or UML use cases as something I'd forever avoid. [1] https://www.incose.org/docs/default-source/enchantment/210310-carson-perspectives-on-the-737max.pdf https://www.incose.org/docs/default-source/enchantment/21031... [2] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_language https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la... [3] https://sebokwiki.org/wiki/Operational_Scenario_(glossary) https://sebokwiki.org/wiki/Operational_Scenario_(glossary) [4] https://en.wikipedia.org/wiki/Object_Process_Methodology https://en.wikipedia.org/wiki/Object_Process_Methodology [5] https://github.com/Systems-Modeling/SysML-v2-Release/blob/master/doc/Intro%20to%20the%20SysML%20v2%20Language-Textual%20Notation.pdf https://github.com/Systems-Modeling/SysML-v2-Release/blob/ma...
oaiey 3y ago
Correct. The big fallacy of agility. Mixing work items with requirements (words like feature or user story are terrible abused here). If you need a specification in an agile project, then it is an output of the work items next to the code.

GrumpyNl 3y ago

You can easily create requirements in Jira.

chrisrickard 3y ago
Correct, you can create requirements anywhere, I just feel requirements are more important, and long-lived than a transitory Jira ticket. E.g. A Jira ticket moves to "Done", the requirement is complete, and people are happy. But the important info on that ticket has essentially disappeared - obviously you can mine your thousands of tickets for historical info - but no one really does.. as it's mixed with bugs, changes, improvements, conversations etc.
okl 3y ago
I don't know how exactly you'd do that and depending on the project it might be fine. One important feature of a requirements tool is that it allows you to "tag" a set/document of requirements with a version that corresponds to your released artifacts and create "diffs" between such versions. I don't think that's possible with plain Jira(?)

dhx 3y ago

I like the personas and journey features. In formal systems engineering, a common mistake (including for the 737MAX[1]) is failing to model system users, and treating system users as completely external and separate to what is being designed. I'd love to play with an Inform 7[2] like language for capturing "operational scenarios"[3] (systems engineering jargon for roughly a combination of "personas" and "journeys"). In many fields of systems engineering (e.g. aviation), vocabulary has to be tightly controlled and syntactically unambiguous language used. As is the case with Userdoc, an LLM could propose operational scenarios, but they'd need to be converted to a syntactically unambiguous language, and be vetted by humans. Of current approaches to formally capturing operational scenarios, and I don't think any of these do a particularly good job of it, I prefer Object Process Methodology[4] (text representation only) over SysMLv2[5] (again text representation only, and this is R&D/draft). I'd only mention SysMLv1 or UML use cases as something I'd forever avoid. [1] https://www.incose.org/docs/default-source/enchantment/210310-carson-perspectives-on-the-737max.pdf https://www.incose.org/docs/default-source/enchantment/21031... [2] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_language https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la... [3] https://sebokwiki.org/wiki/Operational_Scenario_(glossary) https://sebokwiki.org/wiki/Operational_Scenario_(glossary) [4] https://en.wikipedia.org/wiki/Object_Process_Methodology https://en.wikipedia.org/wiki/Object_Process_Methodology [5] https://github.com/Systems-Modeling/SysML-v2-Release/blob/master/doc/Intro%20to%20the%20SysML%20v2%20Language-Textual%20Notation.pdf https://github.com/Systems-Modeling/SysML-v2-Release/blob/ma...

oaiey 3y ago

Correct. The big fallacy of agility. Mixing work items with requirements (words like feature or user story are terrible abused here). If you need a specification in an agile project, then it is an output of the work items next to the code.