Gathering requirements is crucial for a project to succeed; therefore, documents must be precise, measurable, clear, and understandable.
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 on 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 is responsible for delivering 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. In contrast, 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 for 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 criteria, and 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 these requirements considering the due date of the IT project.
User stories are a very important technique that will help developers visualize what the user really wants and help them define a development approach to fulfill the expectations. An example of a user story is as follows:
| ID # | 43 |
| Title | 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 |
| Priority | Should |
| Status | Approved |
| Subsystem | Wake-up |
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 cataloged as must need to be considered as really important and will define the release.
- Should: This requirement is also very important but will not depend on 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 requirement.
In conclusion, the business analyst or the project manager’s responsibility is to define the right scope of the IT project in the BRD. This document should define each requirement and catalog them by their priority so the developer can define the right approach they need to take in order to fulfill the user expectations.
