Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)


How do you avoid requirement conflicts while making changes to an existing system where no documentation exists?


Companies with small IT departments or analysis teams often lack a well defined analysis process. It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist with requirements and new features for a system where no documentation exists.  In this case, the analyst needs to create a minimal amount of documentation retroactively.

Few companies will permit taking the time to completely stop and fully document a system with a heavy weight documentation process. So the analyst needs to start with a lightweight process for documenting features and requirements rapidly.

Features tend to be readily apparent in the implementation of a system. However, the underlining requirements and rationale for the features are not as apparent.  

First the analyst can document features and sub-features quickly using a feature tree diagram (based on the Fishbone Diagram).  This helps organize features hierarchically.  Most features are evident by examining the user interface. However, doing a cursory code review can uncover other less noticeable features as well as business rules associated with many features.  When you find business rules, be sure to document them.  Once feature identification is deemed to be complete the requirements should be documented in list form or in a database so that they can be mapped to business rules and, more importantly, to the requirements that will be documented.

The next step is to identify the requirements which led to the inclusion of the features in the first place. This will allow the team to avoid requirement conflicts in the future. Since we've already stated that time is a luxury it makes sense to use agile techniques to document the requirements rapidly.  User stories are great for such a case. Reach out to the end users of the system and ask them what they use the system for, how they use it and why they use it in the manner they do.  How does the system create value for them?  Construct a quick set of high level User Stories to document the What and Why.  These are your requirements.

The User Stories don't have to be completely detailed out all at once. Create simple 1-3 sentence User Stories representing each requirement.  Along with the user stories, acceptance tests and business rules should be associated to each, but this can be done on an ongoing basis as more is learned about the system through future iterations and updates. 

Once the features have been identified and the user stories have been created, the analyst can map the two together reasonably well.  The organization now has a reasonable understanding of the requirements of the system and can avoid conflicting requirements in the future.

Chris Adams
LinkedIn Profile



Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.



Select ModernAnalyst Content

Register | Login

Copyright 2006-2024 by Modern Analyst Media LLC