Requirements Development
Requirements development is a collaborative activity that involves human interaction, and thereby is imprecise and frustrated. Imprecision arises from the fact that requirements gathering will involve face to face communication, that may be limited in the time available for this activity. Frustrations include lack of engagement of the stakeholders with the correct levels of knowledge or authority, politics and hidden agendas, narrow or distorted views of requirements’ priorities, lack of business knowledge, lack of control of requirements change or project scope, to mention just a few.
No other part of the software development life cycle contributes to project failure as much as poorly gathered requirements. Many third party reports have gathered evidence of this, none being more demonstrative of this than the CHAOS reports that have been published in the past couple of decades.
Whether gathering use cases, or any other form of requirements, this requirements interaction and generation phase is most successful when conducted through iterative refinement. At each iteration interviews or workshops are conducted with stakeholders. The outcome of these workshops are analysed for requirement types and structures. The results are documented (in the form of use cases for the type of requirements we are considering here), and then taken back to the stakeholders for confirmation. These four activities are known as elicitation, analysis, recording, and validation.
Elicitation
Elicitation is the process of actually capturing/negotiating requirements with stakeholders. As such, the expertise lies in forming the right combinations of questions and interview or workshop techniques to be able to construct use case descriptions. Usually this process happens over three or four successive phases for each use case. An initial interview might identify the actors and goals, together with some brief outline description of the expected sequence of interactions that reach these goals. Little or no attention is paid to alternative paths, or failure modes.
After writing up a first brief description of the use cases, these are then taken back to stakeholders so that in a follow up interview or workshop the details can be confirmed or enlarged, and so that initial consideration of alternative paths through the use case can be discussed.
Subsequent workshops would see the production of what are usually termed ‘fully dressed’ use cases, that conform to the more rigid template for describing all facets of the use case. This is the format that the final agreed requirement will take, in the requirements documentation.
Analysis
After interviews and workshops, usually all a requirements analyst will have will be his/her notes capturing the answers to questions asked during elicitation. The analysis phase is used by the analyst to structure the results of these interviews into a standard format requirements model. From the point of view of functional requirements, this means converting the notes into use case descriptions. Naturally there are other parts of the requirements model that need to be structured: A domain data model; a list of non-functional requirements and their correlation to functional requirements that they affect; a glossary; possibly some user interface mockups.
Recording
Possibly the most mechanical phase, this involves editing the evolving requirements documentation so that the new information is written up in the correct parts of the model.
Validation
Validation closes the loop in the iterative process. The written up requirements are used to guide the design of the set of questions or activities to be conducted in the next round of interviews or workshops. The written-up requirements are then gone through with the originating stakeholders to check for correctness, ambiguity, overlap, inconsistencies, missing extra detail. Eventually, the stakeholder will be sufficiently satisfied that a use case represents all they need a particular piece of functionality to do for them. At this point that use case is ready to progress to construction of tests, code, and other documentation.