What software do you use to gather requirements?

I'll probably get downvoted for this but:

https://dilbert.com/strip/2006-01-29

We use a combination of Markdown + PlantUML, CSV, YAML, Structurizr DSL, and Gherkin feature files under Git version control next to the code to structure the requirements and examples. A GitHub Actions continuous integration workflow does validations and compiles reader-friendly documentation with Mkdocs. We are experimenting with consolidating more and more of this into feature files.

We structure the project and its related projects hierarchically along service design packages, similar to the “class-responsibility-collaboration” breakdown in object-oriented design.

All of our stream-aligned team collaborates continuously on this data as part of sprints, including analysts, managers, software and QA engineers. We recently started to collaborate with the enabling Risk & Compliance team on the same data, and started doing compliance audits using the generated, Git hash-versioned reports.

Our other teams use similar combinations of data, mostly centered around Confluence spaces which enable some form of traceability due to bi-directional linking.

JIRA had R4J plug-in that is pretty good if using jira doesn’t upset you. I’ve used it and it works nicely. You get traceability “for free”. There’s additional plugins to enable testing so you can do full requirement to test in JIRA (along with work breakdown if you like that sort of thing). I like JIRA for this because you can put all the conversation about each one in the comments. Gives extra color to the reasoning.

JAMA is a great tool I demoed but couldn’t get the org to buy.

Doors is crap.

I recommend word/ excel if you have <60 requirements. If you have more than a tool like above helps, esp if you need to have traceability to testing.

We are using Notion and are a small business. Feel very comfortable with UI, Templates, Media Types and collaboration functionality.

We have developed almost 40 "templates" to do almost everything we need from Time Tracking, Mental Health, Job Posts, Project Docs, Daily Task Mgmt and Music, etc

I'm using Notion for almost everything (Wiki-style knowledge base, task/requirement management, note taking, gannt-style timeline).

The killer-feature for me is the clean design. If I look at your Excel sheet, it could take me a minute to start understanding what the doc is about. Notion makes so much easier on the eyes and easy to ingest.

My two previous employers have used Rational DOORS and one of them additionally used MagicDraw.

I would advise that you avoid Rational DOORS at all costs.

DOORS is the kind of abomination that is so bad that I wish a meteorite would smite IBM.

Had to use DOORS for years, now we try Sphinx Needs [0] and like Docs-As-Code in combination with your favorite git workflow very much.

[0] https://pypi.org/project/sphinxcontrib-needs/

I'm trying to understand what your workflow is that requires easy-to-use versioning. Aren't you basically always implementing against the current requirements?

I use Google Docs, with difficult-to-use version history if needed unexpectedly. If it's needed expectedly - e.g., because we planned to do something simple, it turned out we needed something more complicated, and we care about documenting for the future why the simple thing doesn't work - then I add a section to the current version of the doc explaining that. Or if implementation started and I need to catch up people who were familiar with the old requirements, then I add a section noting what the changes are.

These docs are generally prose, in the vague space of Amazon-style six-pagers, Architectural Decision Records, RFCs/enhancement proposals (Rust/Python/Kubernetes have great public examples of this), etc.

For extremely complicated requirements, the prose document includes an itemized list of stuff we need to get right, for easy reference, and then a prose explanation of why a particular approach will get them all right.

(In my experience, docs that just have lists are prone to having apparently-contradictory requirements and no explanation of how they're expected to be resolved.)

I use https://cawemo.com/ business process modelling notation (graphical) because it's multiplayer realtime and works well over video.

OneNote for us. I feel like something too formal would add too much bureaucracy to requirements which are often a creative exercise in communication. For example sometimes you need a diagram, a face to face chat, a story etc. to get the ideas across. Getting ideas and concepts across > getting every requirement set in stone for us.

For simple lists, notes, and documentations, (and not spreadsheets), I found gitbook great.

Easy navigation, built-in search, you can have variants (for versioning), less cluttered UI and (anecdotally) good overall performance on mobile and desktop.

Tried asana, dropbox, trello, notion, airtable, and settled with gitbook.

IBM DOORS, but it's probably the worst piece of software I've ever had the misfortune of using.

Excel.

Unless your project is huge (multi billion), requirements gathering is mostly about the BA and others understanding how something will be used. So it's human brain work. Excel is a nice way to keep and monitor lists of requirements and link then together, add dates etc.

It's something everyone can operate (stakeholders to Devs, without a new license or needing to be taught it).

Ive seen a LOT of projects use shiney clever solutions and they always either fall back to people's brains or fall on their face because someone didn't complete the dependency matrix overview page in exactly the way the software needed etc.

My organisation uses Aha (https://www.aha.io/) for all of our products. Personally I like it and I believe it meets both of your requirements.

Regarding 1): it has a structured framework where you define your product vision, then break it down into goals and initiatives, then break the initiatives into features. The dev team further breaks down the work into TFS tickets, and Aha integrates with TFS.

Regarding 2) It does change tracking on everything, so you can view the prior history of any ticket in the system.

We are the authors of Requirement Yogi. It is an extension of Atlassian Confluence (Server/Data Center), the famous intranet for companies, which addresses your versioning question.

- I created it when I received my usual 1000-page spec document in Word, in a waterfall project…

- So the software is excellent at numbering requirements (which addresses your first question about itemization), making links between places in the docs, managing dependencies, and letting people free to format their document on Confluence pages,

- We have excellent feedback from customers, but we are still lacking some enterprise features such as managing a million requirements, or inheritance (customers often have a core product and they derive a custom version for 10 or 50 customers).

What I love is that we’re at the articulation between free text and structured database: Customers want to write free text with images and widgets, and they still want structural queries, such as the completion % of their project, but based on the Jira story associated to each couple of requirements… I love what I’m doing!

https://requirementyogi.com

—Adrien

What a lot of teams in my company do is have a less formal part (more like brainstorming) done with Quip (https://quip.com/) before having the more formal part in Amazon WorkDocs (https://aws.amazon.com/workdocs/... Disclaimer, I work for Amazon). Workdocs is a pretty good tool for versioning, commenting on and sharing Word documents, but it's not great for multiple people working on a document at the same time. Quip is great for multiple people working on a document at the same time, but doesn't really have any versioning mechanism.

For personal stuff, I use emacs org mode in a git repo. Org mode lets you define a hierarchical structure to the topic, hide the hierarchy that's not relevant to the part that you're focused on now, track what things you've done, and when relevant provide supporting information in spreadsheets embedded right there. Worth checking out.

Hi, please check https://www.specprojector.com/en/

It is service (startup) for making functional specifications for IT-products.

Strong workflow:

1. Features map - role 1: feature 1, feature 2 - role 2: feature 3, feature 4 2. User story for each feature: I can, I see... 3. Attaching design from Figma 4. Estimating resources 5. Attaching API: GraphQL, REST 6. Attaching tasks from GitLab, GitHub for tracking spend time 7. Generating tasks description 8. Terms knowledge base 9. Modules 10. Generating invoice & contract

1. Slack

2. Miro

3. Roam Research

Each has advantages and disadvantages used as knowledge systems. Slack is directly accessible for the whole team. You can create #thunderbong-stream, and under a thread link directly to message sources. That's directly readable for others, and you'll encourage discussion if you want.

Miro is better for hierarchical organization. Top-level requirements, (or objectives, outcomes if you will), then smaller pieces below.

We use P2 at Automattic which is pretty decent, and people can leave comments. Links between the posts are listed on them. It’s not perfect, but since it’s searchable, it’s great to find out why something is different by having p2 build up a web of related comments/posts.

It’s always interesting to go back 10 years to understand exactly why a decision was made and even see some of the alternatives.

I've been working on https://sltoo.dev, it stores requirements in text files and tracks them with git.

Import and export with Excel allows everyone to participate, see https://sltoo.dev/workflow.html.

Traceability is a beta-feature at the moment.

Mind Mapping is a no brainer for such situations.

1) I use XMind, which has floating topics. I quickly draft mentioned requirements as a floating topics and then break them down into sub-topics

2) After the requirement is clarified then it's a time for prioritisation and I use priority matrix for that.

3) Then you just unify everything under a central mind map topic and "connect the dots".

Related question… Is your team even preserving requirements, especially once you’ve got a test suite?

Traditionally, Systems Engineering views test as a method to verify requirements. Other verification methods include inspection, analysis, and demonstration. But, as tests become more readable, maybe at some point the tests become the requirements…

I’m currently building something like this, though I don’t currently have anything open for actual consumption yet. I’d be interested to know what you’d expect the system to do.

It’s basically a standalone system, but can connect to confluence to retrieve requirements, and/or Jira to turn requirements into tickets.

It allows you to group requirements into an arbitrary number of levels, and keeps track of any changes to the requirement. Major changes to the contents can be tagged as a new version, which can give you an idea of how many ‘breaking’ changes there are.

If you integrate with Jira, and the original ticket is already completed, then it’ll create a new one for the new version of the requirement.

Ideally it’ll have a planning component at some point (e.g. auto gantt chart), but not yet.

I've seen people using archbee.io for similar use case. Archbee is a lightweight docs tool for developers with various integrations so should check your boxes (full disclosure - I'm an investor there :)

Plain text file + git.

REdmine.org Self hosted for us but there may be hosting providers around.

I use ProductBoard. It's fairly expensive but pretty great. I gather requirements into PB and use the inbuilt editor to flesh them out. When a story is ready I push a button and it ends up in Trello (but you can add your own integrations; there's one for github for example). The integrations aren't perfect but I love it. Used it in my last job and brought it in at my current job.

https://productboard.com

The big problem in the requirements field is the ghastly tooling.

Organise your statements and requirements. Store them in git. Run a simple HTTP server to share with colleagues.

For requirements gathering, if i had full control I’d probably use use cases at a level of formality appropriate to the need in plain text, markdown, or asciidoc for behavioral requirements, some text->diagram solutions (mermaidjs covers a lot, fir instance) for DFDs and ERDs, ans gantt charts, and git for version management of the whole thing.

I’ve mostly used Word for requirements/user stories, you can turn on track changes. I’ve mostly used excel for WBS.

I’ve also seen things like JIRA and Trello used for small projects where you don’t need a formal requirements doc and you’re running it scrum or Kanban.

My experience is mostly in non-technology industries.

I use predefined templates I made in Confluence for requirements and tech specs. Part of the page header in the template has a spot to link to the other docs. I defined a process where the person reviewing the document uses inline comments to keep the history clean.

Maaaany projects use a set of Word documents in a repository.

I have used Workflowy and Trello on a lot of projects, both of which make drag-and-drop prioritizing and bucketing "fun". These days it's usually a quick HackMD shared with the team.

Dynalist

wiki page

Word.