The Who’s Who of Software Requirement Generation and Maintenance
If you were to cast your mind all the way back to last November, you may recall that we published an article advising on how to write software requirement specifications. This month we have decided to once again delve into the realm of requirements, and share our thoughts on who we believe the task of generating and managing requirements should fall to.
When you take a minute to think about the process as a whole, it is unlikely that such a crucial task would be just a one-man job, especially in terms of large scale developments. There may be one person who coordinates and pulls things together, but in reality, there will be a number of other stakeholders that will have an input into the process.
The Business Analyst
It is the responsibility of the business analyst to work with clients in order to elicit and refine the Business Requirements for a system. If you don’t have an individual that falls under this job title within your organisation, don’t panic. It isn’t a necessity for the business analyst to be a part of your team. They can easily be employed by your clients to prepare the Business Requirements prior to your engagement, or maybe even be sourced from a third party, however, their responsibilities will always remain the same.
The Requirements Engineer
While it is nice to have Business Requirements, they do little more than outline the goals and expectations of the client at a high level. In order to establish the fine details on how the system will operate, Business Requirements need to be broken down and outlined as Software or System Requirements. This task falls under the responsibility of the requirements engineer. Due to the technical nature of Software/System Requirements and their impact on the project as a whole, a senior software or system engineer who understands the importance of writing good software requirements should ideally fill the position of requirements engineer.
The Project Manager
There are a lot of similarities between the project manager and the business analyst, so much so that they often end up being the same person. However, they differ significantly when it comes down to the tasks they are responsible for during a development project. Where the business analyst communicates with the customer to gather the initial requirements and understand the problem they are trying to solve, it is the responsibility of the project manager to ‘manage’ the requirements. Ensuring that resources are made available and that the final result is delivered on time and within budget, whilst meeting the expectations of the client, all fall under the responsibilities of the project manager.
In a perfect world, the client would hold total responsibility for creating the requirements for a project, but unfortunately, this is very rarely the case. In many cases clients find themselves lacking the necessary technical expertise, leaving them with an idea of what they want from a system but without the means to detail how they plan to achieve it. However, even in situations where the client has handed over the responsibility for requirements, they should still have the final say and give their approval before any further work begins.
Each of these roles plays a part in the requirements development process but there is nothing saying that they have to all work within the same organisation. Sometimes it can be beneficial to get an external view of the situation and gather ideas that may not have been considered otherwise.