Hacker News Reader

Comment by chrisrickard | Hacker News Reader

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 (currently we are specifically focused on user stories, personas, and journeys).

View on HN

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/21031...

[2] https://en.wikipedia.org/wiki/Inform#Inform_7_programming_la...

[3] https://sebokwiki.org/wiki/Operational_Scenario_(glossary)

[4] https://en.wikipedia.org/wiki/Object_Process_Methodology

[5] https://github.com/Systems-Modeling/SysML-v2-Release/blob/ma...

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.

You can easily create requirements in Jira.

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.

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(?)

Reply on news.ycombinator.com