Gathering requirements for developers is a process that will determine the success of the project. In order to achieve the goal of any IT project, every team must be in the same page. Teams that usually are part of IT projects are Quality Assurance, Business Analysts and Development. In this blog we will talk about certain processes/techniques a Business Analyst or a Project Manager could follow in order to gather good requirements for a developer.
The Business Analyst or the Project Manager, have the responsibility to deliver a business requirement document BRD where all constraints and details in the project are described. This document must have the Quality, Functional, User and Systems requirements the final product should have.
Functional requirements consist of the specific behavior which the software should follow, while the User requirements are the goals or tasks that most users should be able to perform when they are using the final software product. As of the Systems requirements, these should define the operating systems that will be used to run the software.
A good requirement document for a developer must include an objective, be precise, measurable, have a criteria and should be clear and understandable. Some Business Analysts and Project Managers follow the SMART technique for requirements, where each letter of the name has a meaning. In this technique first you need to be Specific in your requirement, guarantee it is Measurable and that it could be Actionable by the code or system you currently have; also it should be Realistic and you should have Time to accomplish this requirements considering the due date of the IT project.
User stories are a very important technique which will help developers visualize what does the user really want and will help them define a development approach in order to fulfill the expectations. An example of a user story is as follows:
||Wake me without disturbing others
| User Story
||As a person who needs help getting up in the morning,
I want the alarm clock to wake me up without waking my partner
The MOSCOW technique is a way to prioritize and define the requirements for developers, as with the SMART technique, MOSCOW is an acronym:
Must: The requirements catalogued as must need to be considered as really important and will define the release.
Should: This type of requirements are very important also but will not be dependent of the release.
Could: These are good to have requirements and are not very important, but still nice to have them if possible.
Won't: The software that will be delivered to the users will not and should not do this requirements.
In conclusion- the responsibility of the Business Analyst or the Project Manager is to define the right scope of the IT project in the BRD. This document should define each requirement and catalogue them by their priority so the developer can define the right approach they need to take in order to fulfill the user expectations.