During elicitation requirements analysts are focused on understanding a CONOPS or Mission Statement and translating this to a more clear and concise format in the form of a requirements document. Modeling can reduce the time required for this effort and improve clarity and understanding. The following diagram illustrates the types of models that are frequently seen throughout the development lifecycle.
Models focused on the elicitation should be simple models that are non-technical in nature. These models should be easy to read and understand. Remember that their purpose is to clarify process flows or process narratives for non-technical end users and stakeholders. Moving immediately to UML or SysML type diagrams are too technical and usually too voluminous for stakeholders to read and understand.
The elicitation process consists of documenting high level capabilities, prioritizing the capabilities, and then using modeling to drill down and clarify how the capability will appear to the user. This technique can make the difference between unclear requirements and clear requirements that are validated and understood by the end users.
A good elicitation strategy is to begin with an outline of a basic process flow or use case with no alternate paths. Review this with the users and get agreement on this first. Once this is completed add alternate paths and document how they should be handled by the system. Do this for each step in the process flow. This will result in a very robust and clear set of requirements that capture details for handling alternate flows that may arise. Keep the language simple and clear and remove any information that doesn’t pertain to the flow itself.
This is the first step in understanding the user’s problem. Next is to figure out what the solution is to the problem!
The elicitation process consists of documenting high level capabilities, prioritizing the capabilities, and then using modeling to drill down and clarify how the capability will appear to the user. This technique can make the difference between unclear requirements and clear requirements that are validated and understood by the end users.
A good elicitation strategy is to begin with an outline of a basic process flow or use case with no alternate paths. Review this with the users and get agreement on this first. Once this is completed add alternate paths and document how they should be handled by the system. Do this for each step in the process flow. This will result in a very robust and clear set of requirements that capture details for handling alternate flows that may arise. Keep the language simple and clear and remove any information that doesn’t pertain to the flow itself.
This is the first step in understanding the user’s problem. Next is to figure out what the solution is to the problem!
By: Marcia Stinson
No comments:
Post a Comment