As with most developers, struggling with poor, vague, incomplete, and not thought out requirements. I know most people feel developers should pull double-duty and help with business analysis, but if you have large number of individual projects, it's hard to be a 'business subject matter expert' for all of them.
So, here is my question - is there a good collection of processes related to developing requirements (requirement life cycle)? Specifically functional, business requirements that a person writing code would need from someone in the line of business/sme/business analysis (example: I want to be able to add another type of member to the system, including driver license requirements and date of birth....which would lead to the next questions of does u.s. state driver license ok, is state id ok versus driver license, does date of birth have certain constraints (i.e. state id for someone under 18 ok, or if senior age relevant), etc).
Requirements Development life Cycle along the lines of -
Idea -> Brainstorming -> High level requirement.
High level requirement broken up into detailed business requirements and technical (non-functional) requirements.
Requirements analysis to compare detailed requirements against existing requirements already in place (if existing system), compared against each requirement to other requirements to ensure non-contradictory, best-effort to ensure requirement is not vague or missing critical details and is as non-ambiguous as possible.
prioritization of requirements, categorization and collection of requirements into deliverable/milestone sets (i.e. these 6 requirements should be completed together, while another 11 should be completed together but at a later stage).
post-implementation, testing the implementation against the requirements and tools/processes/measurement to identify areas to improve on the Requirement Development Lifecycle.
ok, I'm starting to rant a bit, so stopping -- question is, does there exist something that focuses on maturing the requirements process?
-->domain expert/sme who has knowledge (tacit knowledge?), but has very little time or desire to document expectations. In this case, the domain expert/SME acts as the customer, as the customer themselves are looking to the company to solve their business problems in an efficient and quality manner.
-->developer who has skill to help solve problem, but no idea on 'devil in the detail' issues around the problem, or even what 'efficient' or 'quality' represents for that domain.
-->manager who has some resources, but not unlimited resources, wants to make the customer happy.