Kalpesh left a very valid comment on my last post on overcoming the inertia against writing requirements, where he said that this task can be better performed by someone “who understands domain of the customers & enough of technology”.
I fully agree with this comment as, from experience, I have seen dramatically improved results when a person is fully dedicated to the task of writing requirements and who is both knowledgeable in the technology used as well as the business domain. The reasons behind this are:
- A person fully allocated to collecting and managing requirements has a much better feel for the integrity and completeness of the requirements. Since they are always thinking about the requirements, they can easily find and plug gaps in the analysis. When the person does this along with other tasks, they only do analysis when they are writing or gathering requirements, not at other times.
- A requirements analyst fully focused on requirements can continue to develop skills and techniques that help in improving the quality of the documentation. There are many areas of improvement possible: The methods of gathering requirements, the writing and presentation skills, the ease of translation into code, etc.
- A person knowledgeable in technology can help non-technical customers understand what is possible and what not. For example, I have seen many customers use their client/server environment experience to suggest certain web user interfaces. While new technologies like Ajax does allow you to create highly interactive interfaces, there are limits and costs to such user interface demands.
- A person knowledgeable in the business domain is much better placed to understand user needs. However, I have found that most people are capable enough to gain a working understanding of the domain in a few weeks and it is also impossible to know everything because of changing regulations and business environments. But in short-term or critical projects, it is too risky to assign an analyst who is new to the business domain.
Unfortunately, for many organizations, departments and teams, it is not possible (for various reasons like cost, resource availability, etc.) to allocate such a suitably qualified person for requirements alone. Even in many successful software companies (product and service), I have found that the analyst usually doubles up doing a lot of other work such as design and acceptance testing, and sometimes even coding.
One reason for this is that requirements is usually an activity that has a distinct peak of activity (user interviews, documentation, etc.) followed by relatively low effort in maintaining the requirements artifacts. Even a highly detailed requirement needs several times the effort to convert into design, coding and testing. In the meantime, the requirements analyst will be relatively idle. And although they may be called in for clarifications, this would not be a frequent activity if they have done their job right.
In any case, if a team cannot afford a full-time requirements analyst, the developers in the team must take up the task of requirements collection and analysis. And that was my point in my previous article – many developers do not like doing that leading to innumerable problems in project schedules and project quality.
So if you are a project manager in this situation who finds that requirements management gets put on the back burner when compared to coding, you need to understand what exactly is going on. Unless you spend time to train people, remove their fear, allocate dedicated time for analysis and show them meaningful examples, the problem is not going away.