How do I manage the customers’ complex requirements?

How would you handle this scenario? A customer has stated that they the system to be user friendly. I call this a complex requirement because it is effectively a collection of many unique requirements. Elicited requirements should be at an atomic level. In other words, each requirement should be a unique and complete thought. But what is the best way of getting to this level with the customer? Reality (and experience) tell us that that many requirements are actually much more complex than stated.

Remember that we should not expect the customer to give us any good requirements. They are supposed to provide us the problem they want to be solved. If this is not clear then we need to need to ask them! They are expert of the problem. If we pursue this statement a bit more we may find that the requirement is that the Customer must train 500 people in three months to use the new system. Of course it must be user friendly. But what the Customer really needs is a way to ensure new users can be trained quickly. That may change the focus of the solution – user manuals, online training, tutorials, etc.

So let’s take that simple request for a user friendly system. Here are some of the problems.

• A Customer doesn’t want a workshop to determine what user friendly means. The Customer wants us to think for them. After all we are their “consultants”.

• The Customer doesn’t know completely what they want. They haven’t thought through exactly what user friendly means to them. They may have added this because it’s a good idea and everyone else is doing it.

• The Customer is too busy to provide quality input to us. Ask them to spend half an hour talking about what user friendly means to them and they may simply decline to spend the time.

• The Customer may not have determined all of users who are looking for a user friendly system. In other words, he may not have identified everyone who might want to determine if the system is user friendly (e.g. corporate customers, non-corporate, experienced users vs. inexperienced users, foreign customers, etc.).

There are some things that can be done to mitigate the risk associated with a requirement of this type.

• Do some prototyping of screens and show them to the user. Ask them specifically if they think these are user friendly. Then capture the aspects of the screens into a set of user interface requirements.

• Create your own definition of user friendly. Define the criteria and use these to define your user acceptance tests. Provide these to the customer to review.

• Keep pursuing your understanding of the problem. Don’t be afraid to keep asking questions and delve into the real reason behind the customer’s requirement.

• Make sure you have clear criteria to measure the requirement. Without it, you will never pass the requirement in the Customer’s eyes. And without it, the requirement is of no use at all.

By: MARCIA STINSON

Do we really need Requirements Management?

Based on analysis and statistics from several organizations today, we know there is a critical need to adopt a requirements management practice. Let’s start by providing a definition in a simplistic manner. Requirements management represents the process of eliciting, prioritizing, documenting and agreeing on product requirements.

So now, what is the perception of product managers about the importance of this activity in an effective product management process? More specifically, what is the rationale behind adopting a structured approach for the definition of these customer needs? The justification for requirements management is to ensure that organizations meet the expectations and needs of its customers as well as its external and internal stakeholders. However, this is easier said than done. Even when organizations adopt an engineering approach towards software development, the most common pitfall is the customer's ability to verbalize what they want and need in a software product. So the overriding problem is how to ensure that the consumer needs are accurately articulated and analyzed by the product management team before they sent off for development.

We know and understand the importance of this up front elicitation and analysis activity, but we rarely spend the time required to do a good job. On one project I managed, the customer was very upset that we were spending so much time documenting their requirements for a website. Every time they would voice their concern I would ask them a simple question: Do you want the product to do what you expect it to do? Or is just any solution good enough for you. I asked that every time, without fail, when they complained. Of course they wanted it to do what they expected. I kept telling them that they needed to trust me, and believe that this work was essential to getting them the software product that they wanted and their customers would use. They relented. After a few requirements sessions the customer came up to me after a meeting and said “You are absolutely right about this. We have to do this.” Her change of heart came because we found a flaw in our logic that had not been verbalized by them. It was a simple thing. We were going through a use case on transferring funds and had an alternate path when the customer had only one account. The customer asked a simple question. Why do they even see the transfer funds option if they have one account? Good question. So we went back and rewrote the parent use case to remove that option for those customers. I pointed out how easy it was to correct that logic now instead of after they got the product in their hands. I also pointed out that there would be many more of these discoveries that we could correct in the requirements. That customer and I became great friends. The product was delivered and they were happy. There were some bugs and problems. I wish I could say it was bug free. But there were no major issues that required a lot of rework. When I moved on and a new analyst was working with them to document requirements for an upgrade, I heard the customer say “We want to spend time on these requirements so we get the right product at the end.” I felt that a huge battle had been won.

So all I can say is stick to your guns. Don’t let you customers tell you that you don’t need to spend time on requirements elicitation and analysis. Help them understand why they do need these activities and why the time will be well spent. Every time you find a problem and correct it in the requirements remind them of the time and money you just saved. We have an obligation to not only document and analyze requirements, but to help our customers understand why requirements management is critical for them as well.

I think it is obvious from this discussion that I believe in requirements management as a critical piece of any development project. I cannot, with a good conscience, work any other way. I hope that is true for you as well.

By: Marcia Stinson