| TankFish wrote
Ok, great. And the reason you say it should be Solution as opposed to Requirement is because it is the "answer(solution)" to the "question(requirement)"?
Does that mean that when creating a Business doc or a Functional doc that it could be split into two areas. One would be the Functional Requirements where you would outline all the functional needs, rules etc and then the Functional Solutions part where you would outline the solutions and detail what you going to implement to solve the needs.
The System requirements/Solutions seem quite technical, is it not a role more suited to a Solution Architect?
|
Well, maybe I jumped a bit ahead of myself. I see the functional requirements as the bridge to the system solution --sort of a blueprint, maybe? Stakeholders and developers are both involved. I guess what I meant was that sometimes the functional requirements are defined purely by the stakeholders; at other times they entail solutions by the developer. For instance, to me the user name and password screen is more of a proposed security solution by a developer, not a requirement by a stakeholder. Where I work, stakeholders expect everything to be secure by default and depend on the subject matter experts (developers) to accomplish that; but they also want to know, in layman's terms, the functionality of how it's going to be accomplished. Hence the user name and password's inclusion in the functional requirements. The system solution, at least the way we do it, involves only the developers. Where I work, we just have one "Design Solution" document that includes functional requirements/solutions.