It’s no secret that poor requirements lead to poor quality products and that these projects are often filled with scope creep. The challenges with a document based approach to requirements are many, including the fact that it is difficult to keep them up to date in the ever changing of software development. Even if you have done a stellar job in gathering and documenting user requirements the task of managing the requirements has just begun.
Here are some primary reasons for using an automated Requirements Management tool according to Karl Wiegers www.processimpact.com article on Automating Requirements Management).
• Manage versions and changes. Most systems are released in an iterative (or Agile) fashion today. This means that requirements will have versions associated with the release. Being able to track changes and identify the impact of changes is controlling change and scope creep.
• Store additional information about the requirement in requirements attributes. There is so much more we need to know a requirement other than the requirements statement. For example: status of the requirements (in work, approved), priority, who requested it, test status). These are just a few suggestions.
• Link requirements to other system elements. In order to ensure all requirements are part of the product, all requirements are tested, changes are evaluated, etc. we need to be able to link requirements to other system elements.
• Track status. Think of being able to do create a list of all requirements that are not approved, all requirements that are not linked to lower level requirements, and all requirements that are not tested. These are the kinds of information that helps us really know the status of the project.
• View requirements subsets. Think of being able to view all high priority requirements that do not have a test method assigned. Or a security office who wants to review only the security related requirements. Being able to filter requirements to only include information the user is interested in seeing reduces the time required to review these requirements.
• Control access. You will want to make sure that business analysts can only modify user requirements; system analysts can only modify system requirements, and so on. Once approved, access to requirements must be limited so no further changes can be made without a review.
• Communicate with stakeholders. Notification of changes is essential to making sure stakeholders are aware of all potential changes. Most requirements management tools can assist in automatically providing this kind of notification.
For those of us who have used requirements management tools, it is difficult to imagine going back to doing that work on paper. And I believe there are few of us that would choose to go back to that method. I personally would take any requirements management tool over a document-based approach. However it is amazing to me that many organizations of all sizes continue to rely on document-based tools to manage their requirements. Using a Requirements Management tool is a required first step to getting control of requirements.
BY: Marcia Stinson
29 February 2012
15 February 2012
Your Customer Has Rights…. And Responsabilities
Let’s talk about what the customer has a right to expect from us. The customer can expect that analysts will speak the customer’s language and that we will learn about their business. This means we don’t throw a bunch of technical and design requirements at them and ask if this is what they want. Developers will explain their solution and will treat the customer with respect. Developers will NOT tell the customer how they should be using the system. And developers will not become defensive if the customer doesn’t think the proposed solution will meet their needs. The customer can expect that they will be provided opportunities to adjust the requirements as needed, within the defined process. They can expect that we will provide them with good faith estimates for the work. And, above all, they can expect a system that meets their functional and quality needs.
We are often focused on the customer rights, and so is the customer. But sometimes we forget to discuss with them their responsibilities. Often we assume they understand our process and know what their responsibilities are. As a result we don’t bother to tell them what we expect from them. Sometimes we skirt around the issue because we don’t want to “upset” them by telling that we have expectations about what we will receive from them. Sometimes we just don’t even think about it. So what are the customer responsibilities? Well, let’s be clear about what we expect from them.
If we are going to learn about their business they have to teach us. We expect customers to be precise when providing information and to make timely decisions when necessary. We expect customers to prioritize requirements and not just assume all requirements are a “high priority”. We expect customers to review documents that we give them and provide us with real feedback regarding the accuracy of our problem statement (user requirements). We expect customers to communicate changes as soon as possible and not wait until the last minute to provide them to us. Lastly, we expect customers to respect our requirements process. If we expect them to respect our process then we need to make sure we all know what that process is, including the change request process. If we cannot explain our requirements process, then how do we expect customers to understand out process? Being able to help customers understand the process is a critical piece of getting customers on board with our processes.
By communicating this information during the project kick-off meeting we are ensuring that we all understand our responsibilities to each other. It’s not just a one way street. Customers who tell us once what they want and then never communicate again will be the ones who say “I told you what I want, why didn’t you build it?” Analysts who document the requirements and never discuss them with the customer are the ones who say “We built what you told us, you didn’t know what you wanted.” Let’s remember there are responsibilities on both sides. And let’s make sure this is made clear to everyone on the project team. Think about your customers. Do they understand and respect your requirements process?
BY: Marcia Stinson
We are often focused on the customer rights, and so is the customer. But sometimes we forget to discuss with them their responsibilities. Often we assume they understand our process and know what their responsibilities are. As a result we don’t bother to tell them what we expect from them. Sometimes we skirt around the issue because we don’t want to “upset” them by telling that we have expectations about what we will receive from them. Sometimes we just don’t even think about it. So what are the customer responsibilities? Well, let’s be clear about what we expect from them.
If we are going to learn about their business they have to teach us. We expect customers to be precise when providing information and to make timely decisions when necessary. We expect customers to prioritize requirements and not just assume all requirements are a “high priority”. We expect customers to review documents that we give them and provide us with real feedback regarding the accuracy of our problem statement (user requirements). We expect customers to communicate changes as soon as possible and not wait until the last minute to provide them to us. Lastly, we expect customers to respect our requirements process. If we expect them to respect our process then we need to make sure we all know what that process is, including the change request process. If we cannot explain our requirements process, then how do we expect customers to understand out process? Being able to help customers understand the process is a critical piece of getting customers on board with our processes.
By communicating this information during the project kick-off meeting we are ensuring that we all understand our responsibilities to each other. It’s not just a one way street. Customers who tell us once what they want and then never communicate again will be the ones who say “I told you what I want, why didn’t you build it?” Analysts who document the requirements and never discuss them with the customer are the ones who say “We built what you told us, you didn’t know what you wanted.” Let’s remember there are responsibilities on both sides. And let’s make sure this is made clear to everyone on the project team. Think about your customers. Do they understand and respect your requirements process?
BY: Marcia Stinson
Subscribe to:
Posts (Atom)