To begin with, what is the difference between Requirements Management and Requirements Development?
These two together form Requirements Engineering. Requirements Development is the process of eliciting and communicating requirements; and when I say communicating, I don’t just mean writing a requirements document! Requirements Management on the other hand is the process of planning and tracking requirements right from the beginning, from their inception as a vision in the client’s mind all the way until they become an up and running system at the client’s site.
Today, the industry is heading towards what is called Requirements-Driven Project Management. The pioneers of this concept basically advocate that a project is not just about budget, time, and resources; but also about requirements, which form the backbone of the project or the pillars on which the building stands if you wish.
So how should we manage requirements?
Managing requirements involves many exercises; the first of which is planning. Before jumping into the requirements elicitation activities, you need to do some thinking and planning. That in itself involves many things, but let me give you an example. You need for instance to give some thought as to what activities should be carried out to communicate requirements. Not all activities will make sense at all times. For example, in one project, I might have to produce different artifacts to convey the same information (of well! more or less) to different audiences. So I would write detailed system requirements specification document (SRS) for the developers, produce prototypes for the not-so-computer-savvy business users, and prepare an impressive short presentation to impress the executives. These activities are an overhead on the project that I need to plan ahead to avoid surprises down the road.
The second part is to conduct stakeholders analysis - That is preparing profiles for those who can affect or be affected by the project, either in a positive or a negative way. I need to assess if I am actually getting information from the right people and if these requirements are agreed between all the relevant parties. The two essential groups you need to think about are the business users and the decision makers. There are many others of course, but these are the never-miss ones.
There is also requirements prioritization, and reprioritization when needed!
How about the project scope?
Of course there is that too. It is encouraged to give the client the chance to explore all his wishes (be they realistic or not) at the beginning of a project (typically before the proposal phase). Afterwards, when figures are placed on those wishes, everybody return to reality and start drafting a solution with borders that define its scope. These lines are usually drawn in the proposal. Once these border lines are set, all parties need to stick to them. That is not the end of it of course; you need to continuously monitor the scope to ensure that the project is not crossing the border lines.
If at any later time the client decides to extend the scope and accepts the additional cost and time, and you (the IT vendor) have the capacity to accommodate this extension, you can do so and everybody should be happy.
What does scoping involve?
Scoping involves many areas, but let me give you some examples. You need to know who will use the system and what they will use it for. You also need to know if there is any existing systems that the new system will be required to integrate with, and if there is existing data that will need migration to the new data model.
Change is a fact of life. How to prepare for it?
In a matter of fact, to manage change, we need begin before the change actually happens. This involves carefully analyzing the relevant stakeholders as we mentioned earlier, establishing a requirements baseline, and then managing change when it occurs.
What is a baseline?
A baseline is simply a line to which you can compare changes later on. Ideally, the baseline is the signed-off requirements document. In some cases, the proposal itself can serve as a baseline, provided it contains enough details. Once requirements are baselined, it is essential to apply change control management, to ensure careful assessment of the change impact from both the system and the business perspectives and high visibility to all those who care to know about the change.
Where does the traceability matrix fit in this process and how important is it?
“Well-maintained” traceability matrices have many benefits. For one, they serve the important goal of being ready for change. For another, they guarantee that each and every requirement was safely transferred to a component in the system and not missed. Traceability is not done just for the sake of process audits as some people tend to think!
What do we trace to?
A system requirement should be traced back to its business rationale (which could be in a business requirements document, an RFP, or a proposal), and to its source (the person who asked for it); and traced forward to its related design component(s), code package(s), and test case(s).
Of course, to produce an effective traceability matrix, the requirements must be broken down at a good level of granularity and structured in a meaningful way. But that is another topic altogether.
How about risk management?
Requirements risk management is an area we tend to overlook. Today, risk management is applied only on the project level. But, if you think about it, developing the wrong requirements is too serious of a risk for an IT solution provider to absorb. That is why it is important to work on assessing and mitigating requirements-related risks as well. There is something like 12 to 13 risks that relate to requirements, but I’ll give you a couple of examples of typical risks that we frequently face.
The first one is the lack of involvement from essential stakeholders. We mentioned earlier that the business users and decision makers are important partners in almost any project. The business users are the ones who accept or reject the system. We do call it “User Acceptance Testing”! So how can we not involve them in the requirements process and listen to their opinions and needs? Remember also that the users are the ones who know by heart all the little details of the process, mind you that involving them will raise their feeling of ownership and so increases the chance of their accepting and using the system.
What if the client refuses to let you talk to the user?
We need to educate our clients about the value of involving users. Studies prove that this greatly contributes in the success of projects. If you fail to convince the client, try to transfer the risk by getting a formal agreement from the project owners on the client side which states that they are responsible for soliciting the acceptance of the users. Make sure all relevant stakeholders are aware of that.
What if that doesn’t work either?
Well, you will have to take a business decision to either stop working until the issue is solved or continue on your own responsibility.
Likewise, if you have no access to the decision makers - those who can give a go or no-go for your invoices - you are at an equally high risk.
Another risk is conflicting requirements. Person A wants X, while Person B wants Y. This is a conflict that the IT vendor does not need to be part of. All you need to do is to raise the issue to both parties and wait for an agreement. You can explain to them why it is impossible to implement both requirements and possibly suggest alternatives and estimates if required. If they can’t agree, you need to raise a flag to the project owner on the client side.
I must add here that mitigating risks does not need to be carried out in an aggressive way. We after all must cooperate with our clients, so long as we are not compromising the project and its value to our company. Projects are compromised when we fail to manage risks and allow them to become issues. The more planning and open communication we do the better chance we have to deliver solutions that satisfy our clients. It is like standing on a line trying to keep the balance; and balance is a key to success.
Last but not least, we hear of the title Business Analyst and Systems Analyst, what is the difference?
Although the two terms are used interchangeably at times, a Business Analyst is not necessarily a part of the IT function. The Business Analyst works on what is called Enterprise Analysis, which includes activities such as defining the strategic vision of an organization or identifying areas of improvement in the organization’s business processes. Enterprise Analysis is a study subject of its own. However, I must say that due to the fact that IT has lately become an inseparable component in the structure of most organizations, the BA also addresses the need for Information Systems which can benefit the organization by either solving a problem (such as lack of finances management), or taking advantage of an opportunity (such as reaching out to new markets). An IT vendor does not typically have this role; although in some cases the IT vendor may be asked to help out in business processes engineering.
A Systems Analyst, on the other hand, mainly focuses on the IT component. The Systems Analyst core responsibility is to translate the business needs of an organization into system requirements that can be used by software engineers to write code. This is the role you find in IT vendors. In some places, Systems Analysts also work on the application design and even coding.
This article was published in ITWorx Insite Magazine, January 2008
