The document analysis technique is one of the most effective ways of kick-starting the requirements elicitation phase. It is the art of studying relevant business, system and project documentation with the objective of understanding the business, the project background and identifying requirements or opportunities for improvement.
It’s a means of gathering information before scheduling interviews or other elicitation sessions with stakeholders. It can complement other elicitation techniques like workshops, interviews and prototyping by serving as a means of verifying requirements.
To perform document analysis effectively, the analyst should always check the source of documents for possible bias.
Document Analysis is performed in 3 stages:
- Prepare Stage – this involves identifying which materials are suitable and relevant for analysis
- Review Stage – this involves studying the material, taking note of relevant information and listing follow-up questions for the stakeholders
- Wrap up Stage – this stage involves reviewing notes with stakeholders, organising requirements and seeking answers to follow-up questions
Pros of Document Analysis
- Can come in useful where the stakeholder is unavailable or no longer with the organization
- Ensures that the analyst does not start from a blank page
- Acts as a means of cross-checking requirements with other sources
- Document Analysis is limited to the as-is situation
- Documents usually need to be updated to reflect current circumstances
- It can be time-consuming to find and sift through masses of information
Here’s a list of documents that should be considered during document analysis. Analysts should however, be guided by project peculiarities in determining which document contains the relevant information needed:
Business Process Documentation – contains details of current business processes, process participants, handoffs and other process–related information that can help the analyst understand how processes work.
Functional specifications of existing system – contains details of how the current system works and may help the analyst understand any missing features or gaps that can be considered in future versions.
Business Rule Documentation – contains a list of all the business rules that guide the business process in context; it is usually documented separately from the business process.
Organizational Structure – this is a hierarchical representation of the teams or units in an organization, business entities, communication lines and the reporting structure. The analyst can obtain information on which stakeholders to consult during requirements elicitation.
Benchmarking Studies – contain information on industry best practices and the actions that other organisations have taken to achieve success.
Company Memos - company memos may contain project information, meeting updates and requests.
Product Reviews – this is a review of one or more comparable solutions by industry pundits, which typically point at strengths and weaknesses of solutions.
Contracts – contains information like service level agreements, customer expectations and the like.
Customer Suggestions/Feedback – a catalogue of common complaints by customers can be used to generate a list of requirements to consider. It also represents an "outside-in" perspective.
Other documents to be considered are:
- Request for Proposals
- User Requests
- Helpdesk Incident Reports
- System Defect Reports
- Internal Audit Reports
- Training/User Guides
- Related Project Information (Vision documents, Project Charter, etc)
- Annual Reports
- Strategic Plans
- Intranet information
- Previous business analysis documents
- Books, websites and portals
- Management Reports
- Case studies/white papers
- Market research/reports
- Survey/Questionnaire results
- Meeting minutes/emails
- Statement of Work
- Business Plans
- Standard Operating Procedures (SOPs)
- Operational Reports
- Performance Reviews
- Accounting Records
The document analysis technique is an effective way of gathering project information before meeting stakeholders. The analyst can also use the technique for generating questions to ask during other elicitation techniques.
What has been your experience with this technique?