As the first step to any project, gathering and understanding requirements is vital to your success; and yet we spend little to no time on this very important process. Identifying and involving the appropriate stakeholders during the requirements phase is just as important as eliciting those perfect requirements.
I spent many years as a business analyst, and I have found that for me the most effective way to elicit requirements was to conduct requirement workshops. In this workshop, I identify specific topics on my agenda and pick stakeholders with clout, i.e. those that are well versed in their specific business units. Also, I push for using stakeholders from different business units to give the workshop the benefit of multiple perspectives.
The requirements I collect have to be unambiguous and should not be interpreted differently by different stakeholders. This is a difficult task to accomplish because natural language is highly prone to ambiguity, therefore, avoiding subjective words like simple, super-fast, efficient, improved, etc. must be avoided.
Use simple straightforward language from the user’s business domain and avoid making the requirements document into a technical specification and this can be achieved by always keeping the reader of this document in mind.
Another technique I have learned to use is so simple that most analysts forget to use. This is the simple question of asking WHY. Keep prodding your stakeholders with the simple “WHY” and you will find that your stakeholder will weave a story around their requirement. A user story takes a complex requirement and breaks it down into something simple and concise where you can identify the ‘who’, ‘what’ and the ‘why’.
Can I build test scripts and link them to my requirements? This is a question I ask myself when eliciting requirements. If the answer is yes, then I think I have done a good job in keeping it simple and unambiguous. My “simple” requirement must be the input source to creating a test scenario and this scenario should be broken down into test scripts that can proof out the end result of the requirement. If this can be accomplished then the requirement is complete and there is no further discussion needed on this requirement.
The other very simple and most used technique I most often use is the observation method. This method provides me with the ability to better understand about the stakeholder’s domain. I merely shadow and ask questions where necessary while sitting and observing the stakeholder do their day-to-day business. This method is very useful when your stakeholders find it difficult to verbalize their requirements. The process of observing your stakeholders is rather easy but the documenting these requirements and articulating them in words that are simple for everyone to understand is difficult.
Remember that a critical part of requirements gathering/documenting is the process of scope verification to ensure that you as the customer have received all that you stated at the start of the project. For this task, the requirements are vital. When they are simple and easy to understand, the process of verifying they were actually delivered is just as easy.
Therefore, KEEP IT SIMPLE.
AMIT TRASI | Project Manager
Amit is responsible for institutionalizing project management governance at KTL to streamline ERP implementations. With over 15 years of technology experience as a software developer, project manager, and program manager, Amit has managed end-to-end ERP implementations with Dynamics NAV and GP as well as POS implementation with e-Commerce front end. He holds extensive experience deploying POS and ERP applications at non-profits, theme parks, and museums across the United States. Amit joined KTL in October of 2013 and holds an MBA in Information Systems as well as holding a Project Management Professional certificate.
