Ask HN: How do you specify your (software) requirements?

I'm in a regulated industry, and we'd be considered a "very small entity". What we're doing is likely overkill for you, but how we go about things might be of interest.

We develop under a spiral process and requirements are right at the threshold of when we're going under design control. We start out in Emacs org-mode. I developed a custom template and scripts that tries, to the best of my ability, to corral people into following ISO 29148. The engineering team uses a table view to track the requirements while we're collecting them, and there is a script to export into a pretty LaTeX document for stakeholders to view and redline. We keep the requirements in org-mode while we're collecting them because plain text is easy (and nice) to deal with for revision control. Everything is maintained in Fossil while it's in this state. Once we've ready to lock the requirements under design controls, we export into Excel via CSV for V&V. Under design controls, paper hardcopies become the authoritative record; doing things electronically is too expensive for us.

It'd be neat to one day be fully electronic throughout the process… I could easily see many groups being able to keep things fully electronic, and org-mode is a nice foundation to build a system on top of: it's just structured enough, but at the end of the day it's human-readable text. Heinlein said "once you're in low Earth orbit you're halfway to anywhere", I say, "once you're in org-mode, you're half way to anywhere".

It depends on what you are building.

I try to start every project as a mvp. Minimum features minimum screens minimum and short delivery dates.

For mvps we usually take it from whiteboards to google presentations. We literally paste in a photo of the whiteboard and then add text boxes.

That usually evolves with more slides to more witeframy-ish sketches with annotations.

As a rule we never spec more than a couple of screens and functions.

Once done it gets handed to a dev (with an in-person briefing). They usually deliver something clickable in bootstrap which is great for web and mobile prototyping.

We test on users, get feedback, and start again.

For functional specs, we create a page on our wiki and transcribe the results of whiteboarding and bullshitting. Features are listed out, pictures taken and inserted, and then that wiki page is fleshed in with implementation details (database calls, HTTP endpoints, etc.) as they become coalesced.

In parallel to this, a business use case is put together to remind us why we're building a feature.

Eventually, one or more tickets are opened up in Github via Huboard, and they reference concrete implementation steps and pass/fail criteria.