Requirements discovery is also often referred to as requirements elicitation, requirements gathering, requirements analysis, and requirements definition. We prefer to use the term because it’s a little less high-brow, more meaningful, and more appropriate to the activity it is intended to describe.
The Requirements Discovery Process
The typical process for requirements discovery involves the following six activities:
- Requirements Planning
- Requirements Elicitation
- Requirements Analysis & Documentation
- Requirements Verification & Review
- Requirements Validation & Acceptance
- Requirements Change Management
Origin of the Term Requirements Discovery
The term was initial coined by Ross Little in the late 80’s. Ross, now a principal with IAG Consulting, adapted the term from the legal profession. As a practicing Business Analyst, Little was working to evolve methods, practices and standards from the worlds of structured systems analysis, software engineering, total quality management and business process reengineering. Little credits his father, a lawyer, introducing him to the legal discovery process – and the genesis of the idea to apply some of those concepts to how organizations should gather information to define requirements for business solutions and change.
In the legal community “discovery” is the approach used to determine the facts about a case. Legal discovery mechanisms may be traced back to procedures of the ecclesiastical courts in England as early as the 16th century in which litigants delivered pleadings and obtained answers by means of examination under oath. As legal discovery in American law is the pretrial phase of a lawsuit, requirements discovery is the pre-design phase of a business transformation, or application development project.
In the legal discovery process, ‘witnesses’ are ‘examined’ prior to trial by means of ‘questions’ in an ‘examination’. Their ‘testimony’ is recorded by an ‘examiner’ and written as a ‘deposition’. In the requirements discovery process for application development, ‘subject matter experts’ are ‘engaged’ prior to the ‘design and development’ by means of ‘modeling and questioning’ in a ‘Requirements Discovery Session’. Their ‘requirements’ are record by a ‘business analyst’ and written in a ‘requirements document’.
Fundamental to the process, as in the legal world, discovery absolutely requires the direct involvement of the subject matter experts (the witnesses). Imagine a legal process where the lawyers determined the facts of the case without questioning the involved parties. Similarly, a requirements process would be doomed to failure if the business analysts and project managers wrote the specification (the testimony) themselves without the users and experts. (It would be nice if business analysts could compel subject matter experts to participate through subpoenas, though)
Like the legal discovery process there are a variety of methods of discovery: oral discovery in joint meetings, discovery by written questions and answers (surveys), documentary discovery (examining pre-existing documents, systems, models, etc.)