Proface

Karl Wiegers, who is the author of the most important book in Business Analysis – the Art of Software Requirements’ says “If you don’t get the requirements right, it doesn’t matter how well you do anything else.” This highlights how important it is for a Business Analyst to elicit, analyze and write good requirements.

Although there is no Holy Grail of writing requirements and each business analyst develops her or his own technique, there are certain strategies which are effective today as they were fifty years ago. The purpose of this article is to describe three ways in which a business analyst can ensure that the requirements are correct from the beginning.

Scope Agreement: Requirements Scope Document contains adequate information for the project team to implement the desired requirements on time and within budget. It is a good practice to agree upon the requirements scope from the beginning. A clear definition of the project scope and requirements scope helps all the team members maintain the focus on the immediate ‘needs’ of the business. In turn, this enables efficient use of everyone’s time. Agreeing upon the scope and controlling the scope should be Business Analysis ongoing tasks from day one. In-scope items and out-of-scope items should be marked for budget, deadline, feature delivery, customer satisfaction. When items are out-of-scope, it should still be articulated why they are out-of-scope. Some requirement chunks may be included in later releases. Such clear delineation allows a Business Analyst to keep the Requirement Workshops focused and drive the requirements to closure.

Requirement Models: Second good practice is to document requirements using at least two different models. No model is perfect but all models are useful. One requirement model may highlight one aspect of the requirement but another may uncover related aspects of the same requirement. Textual as well as graphical models may be used to represent user requirements. A business analyst is a ‘liaison’ between the solution team and the business users. It is important for a business analyst to remember that some people understand more accurately with words while some grasp concepts better when they are depicted visually.

Requirement1: Upon entering valid user ID and password, the system shall display a protected page.

Requirement2: Upon entering an invalid user ID and password, the system shall display an error message. The error message shall read, “Either the user ID or the password is invalid. Please check and re-enter. If you have forgotten your password, please use the ‘forgot password link’.

Iterative Lessons Learnt Document: At the end of each release of requirements, it is a good practice to document the lessons learnt. This gives chance to the solution team to explore and document what works, what does not work, practices which worked during that release and those which need to be modified. Short lessons learnt meetings draw deliberate and methodical focus to the process improvement for requirements. Let’s say that with a particular set of stakeholders, sending them requirements for validation in smaller chunks was beneficial then it should be documented. Projects are quite agile these days and project teams are sometimes volatile too. Documenting these lessons learnt helps other Business Analysts who are transitioning on to the project to maintain the momentum.

Join one of our courses at Business Analysis Program to learn more about Requirements!