Follow us...

Determining Project Requirements  

By Teresa Bennett, Business Analyst and Mentor, The Analyst Coach, LLC  
It's obvious that every project has requirements. Some requirements are crucial to the product, while others are luxuries (nice-to-haves). 
There is always someone from the project team who performs the role of requirements gathering for every software project. Ideally this would be a business analyst with the skills and training necessary to get to the real requirements with the ability to assist with determining what is necessary and what falls in that "nice-to-have" category. 
Determining the project requirements is vital in developing successful software as they form a baseline between the IT team, the customers and the stakeholders on what features will be delivered in the new system. 
The person who will be taking the ownership for defining the project requirements needs to be decided at the beginning of the project. If this is not resolved in the early stages of the project then the ownership falls on the development team by default, which will lead to incomplete and inaccurate requirements. Not because the development team is not competent, but because requirements elicitation is a completely different skill set from development and writing code. 
Suggested ways to handle the requirements elicitation process: 
  • Different users have different project requirements. Break those users into groups based on the perspective they are coming from (e.g. customer service reps will give requirements based on customer inquiries for orders, but inventory reps will give requirements based on warehouse tasks to fulfill those orders).
  • Use conflict resolution techniques to resolve varying opinions on what the correct requirement should be. You want to resolve those differences immediately when they come up. If you say "we'll deal with that later", later will come faster than you think and you won't have a resolution when you need it.
  • Users will sometimes believe that the development team should already know what the users need. Make sure the users understand that your intention is to build a product that meets their needs and therefore input from them is invaluable.
One issue you may see on a frequent basis when you are going through the requirements elicitation process is a subject matter expert (SME) giving you a requirement that’s actually what they perceive as the solution to a problem. For example, I had a SME once tell me they needed a report and they gave me a report name. I started by asking what they were using the report for and I then asked three more questions and by the time I was finished asking questions, I had a completely different requirement. 
When the SME said they needed this report, they thought the only solution to their business problem was getting this report in order to use it to perform a manual process. By asking questions and getting to the “real” requirement, I was able to pass that requirement to the development team and they were able to come up with a more automated way to solve the business problem.
On the other hand, requirements given by the user community will sometimes conflict with what developers think they can build. Communication is key at this point between the business analyst and the development team. 
The development team should clearly articulate why they are not able to meet a requirement and suggestions for alternatives need to be discussed. The business analyst would then need to discuss the alternatives with the business sponsor to decide on a resolution. 
As a BA, how you approach determining requirements is just as important as getting those requirements. Remember to take the time to decide on an approach and plan your elicitation activities before diving in to the requirements elicitation meetings.
Teresa Bennett is a Business Analyst Consultant and founder of The Analyst Coach, a company through which she mentors current and future business analysts around the world at any stage of their IT career. Teresa has 20 years of demonstrated success as a business analyst and software tester and brings that experience to people interested in career growth through her online training and one-on-one coaching sessions. You can go to to read more about Teresa.