(a) In particular, is the PRD -> SRD -> Design -> Implementation -> Testing flow still used?
(b) What do you use to capture the UI aspects and requirements?
(c) How are tool choices made when similar tools exist?
Pointing me to a set of "starter" web links would be just fine.
1. Product Owner creates mockups of desired flow/functionality in Balsamiq. Including acceptance criteria for QA.
2. Architect questions, reviews mockups, annotates with API calls (existing or new)
3. Mockups passed to UI designer who provides design and resources for developers
4. Development
5. Release, QA & UAT once passed
Key to this approach is (a) a product owner who is has a technical background so you start from something sensible, (b) not letting the product owner build UIs but rather flow & functionality (so the designer has free reign), (c) not taking on too much within a single project (eg a fully fledged app from scratch would be multiple iterations of this).
If it is an incremental change or a change related to a growth experiment, during step (1) we set the hypothesis (Eg increase conversion rate through funnel X) and on deployment is evaluated.
If the change has significant architecture / backend implications the architect specs these out separately using either a checklist or a functional spec which is then broken down into JIRA tickets.
We are a small team, but I have found this approach works in larger orgs too. Any time we have started with BRD/PRD etc I find they get outdated fast. Documentation heavy methods have been helpful work for architecture backend changes though.
2. Try to hack it with as fast as possible - Google Forms, spreadsheets, PowerPoint, Evernote, WordPress. For a lot of things with a database, you should be able to prototype faster with a spreadsheet.
3. At some point, it will fall apart. Design a disposable prototype. Plan to throw this prototype away completely.
4. Hack away at the prototype for max 1 month. This should be enough to present to a investor or even release to a customer. (one of my prototypes got 10k downloads, good cash flow, crashed on average 3 times a day)
5. Build a proper design around this. If you have released your prototype to the client, you know clearly what they want.
6. Break down customer requirements into test cases. As in plaintext tests, not code or Word documents.
7. Design a plan for development to launch. Try to launch as soon as possible. Cut features out ruthlessly.
8. Launch. Iterate.
In the early stages, pick the fastest tool. Pick a tool you know or can learn fast.
Every design, scale up 10x. Your spreadsheet might handle 10 customers. Your app prototype might handle 100. Your first non beta release might handle 1000 customers. Future releases handle 10000, 100k and so on. Don't scale too early; tools that scale well are generally less efficient, and this includes marketing.