
Ask HN: How do you specify your (software) requirements? - enrmarc
Do you use a Jira task + a paragraph?
Do you use a template?
Do you specify them just talking in a meeting?<p>In the company I&#x27;m working at as a front end developer, it varies from a simple paragraph in a Jira task to a non-so-rigorous-sometimes-vague description in a Confluence page plus some screenshots of the UI provided by UX guys.<p>It is mostly ad-hoc and since the company has many sub-projects within the big one (let say: payments, global features, savings, etc.) it is always hard when you switch to another project and you want to know &quot;what the scope of the project is, the things it should do and the things it shouldn&#x27;t&quot;<p>I would like to improve this. How do you handle your requirements?<p>PS. I guess &quot;requirements specification&quot; is the correct term. But, in case of doubts, what I want to know is how do you specify the functional requirements your app&#x2F;project&#x2F;whatever must address.
======
OopsCriticality
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".

------
sheraz
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.

------
angersock
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.

