One of the main job responsibilities of a project manager (PM) is collecting requirements and putting them into a prd template. The customer brings a description of a certain subject area for which the implementation needs to be programmed. In our case, this is usually a web project. Where to begin? How to convey to the developer, or rather to the development team, the essence of the task and what they need to do? In a simplified way, the process looks like this: collecting requirements, clarifying them, writing terms of reference, implementation. Let’s talk about the first part of the chain – collecting requirements and clarifying them.
Correct product requirements document template is a document in which the customer described everything he knows about the subject area, how the project should be used by the User, how the customer would like to manage the project, showed the design, thought about future development. Dreaming, as they say, is not harmful. Because it never happens.
Table of Contents
How Requirements Usually Come
Requirements can come through the task management system, by mail, via Skype, at a meeting, in a conversation. The quality and detail of the descriptions are generally poor and require clarification.
What Are The Problems
The customer does not know or is not fully aware of what the employer / top manager wants from him, and, accordingly, cannot formulate the requirements for the task. In this case, it is better not to come to the developers with the task, nothing good will come of such a project. Better to go the other way and get information from the original source for the product requirements document template.
If the customer has the above problems, he offers to do it “somehow”, “at your discretion.” Blank spots in requirements and suggestions “to do it somehow” are evil. You cannot write an algorithm “somehow”, everything in it must be strict. A young developer, looking at such a description, will make surprised eyes, and an experienced developer will program it in his own way. In the first case, the task will not be completed; in the second, it will not be performed as the business needs.
How Can We Make Everyone Feel Good
It is better to describe the initial requirements yourself and set out in the prd. In the process of presenting the problem “on paper”, the author imagines a future project, models it in his mind. This leads to the fact that new features of the functionality emerge, new ideas appear, the description becomes overgrown with details. The requirements that the customer previously wrote in the form of a document are obtained of better quality and more complete as in prd example.
You need a quick feedback to clarify requirements and make decisions. In life, it is not always possible to get quick feedback, for example, when the customer is top and it is difficult to reach him.
Requirements need to be detailed until the developers have no questions. Of course, they will appear during the coding process, but we will fix the requirements exactly in the state when the developer for the first time understood everything about them. Requirements detailing is a joint work of the PM and the customer. Real-life example: the initial requirements received from the customer on one page (with two pictures on it), after clarification turned into 19 pages. That is, 18 pages of information were drawn from the customer in the process of approving requirements, which were brought to the level of detail that was required to start development.
There is no need to design the architecture in the product requirements document example. There are level 80 pumped customers who delve into the topic so deeply that in the requirements they begin to design an application or build a database schema. It’s too much. There is always a person on the side of the development team who will come up with the architecture and will be responsible for it. But these people do not like to be responsible for the architecture imposed on them from the outside.