Business Analysis

Requirements Management Process, Analyzed

m-shaaban — Tue, 02 Jun 2009 15:33:20 GMT

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.

Source: http://www.reqmaster.com

Created by: Dahlia Biazid - January 2008

Managing the Requirements Process

m-shaaban — Tue, 02 Jun 2009 14:08:02 GMT

Numerous software methodologies are currently available for organizations to choose from and employ in their software projects development lifecycles. Smart organizations approach each project with a fresh perspective, picking the methodology that best fits the project conditions. Project’s size, complexity, timeframe, client’s style are all examples of the factors that contribute in the decision of which methodology to adopt.

Some projects go down the path of traditional methodologies such as Waterfall or Spiral; while other ones set on the path of more unconventional methodologies, namely Agile or XP.

Methodologies impact the way requirements are handled in projects, particularly by determining the timing of executing certain requirements-related tasks and the thoroughness of these artifacts at different times throughout the project lifecycle. But incorporating the principles of managing requirements in the overall project management activities will undeniably remain a critical necessity for the success of any project, regardless of how heavyweight or lightweight the adopted methodology is.

Whether requirements are being developed in consecutive, incremental, or parallel fashion; and whether they are communicated in documents, repositories, or Wikis; the rules and exercises of managing the requirements process can be abstracted to two states: Awareness and Preparedness. So long as these two states are alive in the project, the bits and pieces of application can vary without affecting the end result.

By adapting the fundamental principles of the Requirements Management Process to the varied used methodologies, we would be in fact “Managing the Requirements Process” in any shape it takes following the adopted methodology.

This article attempts at summarizing the requirements management exercises that should be honored in any project – regardless of its running style - as they relate to the two previously mentioned states: Awareness and Preparedness.

Stakeholders Analysis: Who are we doing it for?

Profiling those who will benefit (or not) from the project is the first healthy step to prepare for the trip. You need to be aware of those who will be sailing through the project with you. Who has the information you need? Who can validate it? Who needs to approve decisions? Who will authorize payments? Who will constantly work with your solution? The two essential groups you can not afford to overlook in this profiling exercise are the decision makers and business users. These are the “never-miss” groups. Each group is likely to need a distinctive communication strategy. Recognizing such need ahead will save you surprises down the road.

Hence, planning the requirements-related activities

Activities Planning: What shall we do?

Activities related to requirements constitute an essential component of software projects; and they are not a one-size-fit-all type of work. Not all activities will make sense at all times for all projects. For example, how many times have you found yourself wondering “will the users understand the SRS?” or “will the CEO have the span to read through the system use cases?” Your concerns are valid. Different audiences present different categories of stakeholders; and each category has its own way of relating to the world, and to the project. That is why you may end up producing multiple artifacts with more or less the same information but in different styles of presentation to ensure everybody is happy and, more importantly, aligned. Sure developers will appreciate a detailed system requirements specification document (SRS); whereas the not-so-computer-savvy business users might appreciate prototypes or use cases; the executives, on another hand, will do with an impressive 20-minutes presentation.

Defining the activities needed to develop, maintain, validate, and communicate requirements ahead in a plan is like sketching a high-level map of the roads that the team needs to follow to get to the destination. It helps avoid surprises down the road that could affect the project schedule and budget. Although defining the activities may not be possible until you collect some information about the project and the people involved, it is wise to think about them as early as the situation allows.

Roles Assignment: Who shall do it?

Nothing frustrates a team and inhibits its freedom to take initiative and innovate as much as not knowing what exactly is the role of each of its members, or having fuzzy borders between responsibilities. I am yet to meet a team who appreciates crossing and stepping on each other’s toes while carrying out work tasks.

Clearly defining the role of each member, and communicating these roles to all involved guarantees synchronization; prevents frustration; and ensures the project’s time, budget, and resources are efficiently utilized. The possibility of having more than one person unnecessarily performing the same activity, or the possibility of missing an important task because no one picked it up, is an overhead and a waste of time and money that can dramatically damage the project.

Prioritization: What is important? I mean what is really important? Well, how about what is more important?!

No one seems to think requirements prioritization is even possible; clients feel - more frequently than not - equally attached to all their requirements. Of course, they are! They wouldn’t have asked for them to begin with if they weren’t. While BAs and PMs seem to be the only ones who appreciate the beauty and value of prioritizing requirements, the whole matter is out of their control; it is in the client’s hands. Clients resist letting go of requirements or delaying their delivery either for genuine valid reasons or out of pure emotional attachment. If you are able to differentiate the reasons, you are in a better position to negotiate the ones that their postponement would not dramatically affect the client’s business. By involving the right people and building a good valid case, you can still negotiate a fair deal. Remember that it is totally legitimate to reprioritize whenever new factors that necessitate change emerge!

Managing Scope: Wait a minute; is this in or out of scope?

Assuming that you were prepared and have carefully outlined the original project scope, scope creeps that take place later should not be very dangerous. After all, an extra piece here or there will not kill the project.

For more on scoping software projects, read my other article “Starting IT Projects on the Right Foot”: http://www.requirementsnetwork.com/node/1341

However, there are times when requirements must be revisited and the project re-scoped due to events outside the control of the involved parties. As long as you are aware of that, both parties can cooperate to reach a satisfactory solution, such as: Expanding the scope - provided that the additional cost and time are accepted and the vendor has the capacity to accommodate the expansion, trading off some of the original requirements (that have not yet been developed) with new ones, or waiting for next releases.

Change: I see it coming, are you ready?

If your final product still looked on its deployment date the same way it did when the first set of requirements were handed to you, let me tell you that you are one of the few extremely lucky ones in this world who lived to see such phenomenon when software reality matched the dream on papers!

An up and running system rarely looks similar to the original sets of requirements; this is because visions have their own way of evolving and changing form on their way to becoming reality.

Requirements change for all sorts of reasons: A change in business, market, or investment environment; users develop new needs; developers discover new possibilities or constraints, or recognize misunderstandings in the original requirements. We all know that change is a fact of life that we have no ability to stop. Preparedness and adaptation are the only practical tricks we can employ to stay in command and sail through the lifecycle of the project smoothly and pleasantly as much as our authority and position allow us.

Changes are not that bad in themselves, on the opposite, they can improve the product quality; but uncontrolled changes can be a perfect recipe for failing a project. So unless you want the project to fail, you must keep a state of awareness and readiness to handle changes.

The first you should look for in your checklist of Change-Avert enabling items is “Have you got a more or less clear roughly-measurable scope?” Do you know who gave you the requirements and why they were required? Do you have a baseline – a version of requirements that everybody is working on? Most importantly, are you honoring this baseline and carefully tracking who changes it, when, how, and why? Are the requirements structured in a straightforward way at a good level of modularity and granularity; and are the traceability trees kept up to date – beginning from the source and reasoning behind the requirements down to the system components and test cases?

Tim Moore, a Senior Consultant in Experimentus skillfully details the process of change management in his article “Ensuring Change Control Procedures are in Place”: http://www.requirementsnetwork.com/node/1441

Risks Management: Can’t afford to loose it? Then don’t risk it!

While some risks are benign by nature and do not impose great threats to a project (what if your stakeholders are located in different locations? The project can still survive with careful communication), other ones have got the potential to greatly damage the project (what if those who will place the green or red mark on your deliverable to authorize payments are not involved in the major decisions taken along the way?).

Are you maintaining a good level of awareness about the requirements-related risks and their seriousness? Awareness means that you are keeping your eyes on the risks, routinely calculating the odds of their turning into real issues, doing what is needed to keep them in check, detecting when they are about to cause problems, and having some idea about the way to react in the unfortunate event of the risks materializing and turning into real problems.

To conclude, we now know well enough that managing a project is more than managing its budget, time, and resources; it is also about managing the client’s needs, which form the pillars on which the building stands. Requirements are - and will always be - the backbone of any software project. Not managing them by being prepared and aware is risking more than we can afford to loose.

Source: http://www.reqmaster.com

Created by: Dahlia Biazid - March 2009