3 ms·
To me, the most laborious part of the requirements-gathering process, isn't anything to do with driving the collection of the client's description of the proble
by derefr 5y ago
To me, the most laborious part of the requirements-gathering process, isn't anything to do with driving the collection of the client's description of the problem domain and (hypothetical) solution domain.
Instead, it's:
1. having domain experts understand the requirements well-enough to recognize and push back on impossible/impractical requirements (this being the reason the person doing the requirements-gathering is almost always an engineer of some kind); and
2. communicating that impossibility/impracticality back to the client, so that they'll understand it well-enough to be able to iterate on the requirements (or, potentially, realize that the problem is now entirely impossible/impractical to be solved with the general approach they have in mind.)
Is there any tool in this category that tries to eliminate at least some of this human labor, acting as a "compiler for requirements" that can be fed "requirements validation rules" — or maybe constructing the requirements into an expert system or proof-language and running it to find contradictions?
Not as something to assist the engineer in validating, to be clear (there's plenty of those); but rather as something to sit as the equivalent of a "level-one CSR" in front of engineers, to give some level of pre-validation to things before they're tasked with fully validating them. Something that could live on the backend of a "Requirements Elicitation" tool like this, to act as a CI system, preventing clients from "finalizing" their requirements until they've corrected any obvious errors.