Documentation Review:

It is a review of the existing documents like

• User Guides
• Prior system implementation document
• Lesson learned after completion of a project
• Technical documentation (Technical design specs to understand the current system e.g. Entity-Relationship diagram, Activity diagrams, etc)

It is ideally done at the beginning of a project. This will give you an understanding of the context and scope of the project.

You can also use the project documentation during the elicitation phase to understand the current system and also to validate the user/interviewee responses.

Don’t ask for documentation in a random way and instead be specific.

E.g. For an HR System

Instead of saying, “Provide me with all the documentation of the system”.

• You may first ask for the documentation of the employee onboarding process e.g. user guides, new hire process guide, etc (you can be even more specific and ask for the hard copies and soft copies utilized for the process)
• Then you may ask for the documentation of the system (documents will be different if it was built inhouse or if it was purchased and customized)
• etc.

Use documentation only to get a basic understanding of the current process/system. Do not make any decisions based on it because they are very rarely up-to-date.

As you review the current system, go beyond the confines of the current system else you’ll end up mimicking the current system in the future system.

Hence don’t try to figure out the problems in the current system. Go beyond the current system and think in terms of the future system. Think of ways you can provide additional features and functionalities or modify/delete the current functionalities to improve the future system.

Advantages of Documentation Review

• It gives you a good starting point to understand the current process/system.
• It can be used before any other requirements elicitation technique.

Disadvantages:

• Existing documents may be old and outdated.
• Domain or Technical Expertise may be required
  • You need to have a domain and technical expertise to determine if existing documents are accurate ie. whether the document accurately reflects the current system or they have become obsolete. Use the documentation only as a starting point and not the reflection of the current system.
• Reviewing documents is a time-consuming process and the return on effort may be poor.

Best Practices:

• Know the purpose of reviewing. This way, if you are not getting what you want through the documentation then you can stop the review.
• Set self-imposed time limits. Spend a few hours instead of days/weeks. Your focus should be on the new system and its requirements and not on the pain points of the current system. You don’t want to become an expert of the current system.
• Create a glossary of terms from previous project documentations.

The post is  based on my notes and understanding from this BA tutorial