Go Visual - Gain Project Governance II - Things you have never seen in I...

Describing your requirements management structure graphically will immediately take you to a new level of Project Governance by enforcing an element schema and requirements traceability policy.

Visure for IBM DOORS migration

Migrate complete DOORS projects from the aged and expensive platform to Visure Requirements in a safe and easy way. Three easy steps: Select your project, export the whole project with a single click, and import it into Visure Requirements.

Finetune your Visure Requirements project to take advantage of extended views capabilities in Visure Requirements and othe available functionality.

This automated migration will move all your data including links, baselines, baseline sets, attributes, types, users, groups in one step.

Classic Use Case Mistakes

Over the years I have come to understand the role of use cases in the requirements definition activities. They are very valuable if done properly. The problem I continue to see in many organizations is that they are not done properly. So what are some of the mistakes that can help ensure you are getting the most value from your use cases? 

Mistake Number 1: Creating inside-out user cases. 

Results: Use cases that are written from the perspective of the system, not the user. These use cases are often complex and technical. The problem is that most of the time users don’t understand this because it is not natural to them. This makes it difficult to get valuable feedback from the users. 

Actions: Make sure the user’s perspective is maintained when writing use cases. 

Mistake Number 2: Including user interface details in use cases.

Results: Use cases that include a lot of steps that really don’t contribute to understanding how the user will interact with the system. You may see details about where error message are displayed, radio buttons, links, other details about a screen that add to the confusion. Often use case writers try to include every possible action as a part of the use case flow. For example, every possible selection has an alternate flow titled “User Selects Cancel Button”. Adding all of these alternate flows results in a use case that is much more complex that it needs to be. 

Actions: During requirements gathering keep the user interface details out. They are a distraction from defining the interactions that need to occur. Consider keeping user interface requirements in a separate section. This can be used as a checklist when testing to make sure the entire set of interface requirements are met for each screen. 

Mistake Number 3: Expanding the system boundary. It is difficult to keep in mind the scope of the system you’re developing. For example, consider other systems that interact with the system under development. Is it inside the boundary? Is it an actor? Should it not be shown on the use case diagrams? Results: When actors are included which are outside the control of the team, a lot of time is spent documenting a system that already exists and will not be changed. A lot of time will be spent explaining to users that the system just “works the way it does”. You are better off not including details about systems that are outside the boundary of the system. 

Actions: If the team is responsible for implementing and testing it, then it is inside the system boundary. If it is a separate system done by a separate team, it becomes an actor. 

Mistake Number 4: Creating use case interactions that don’t provide value to an actor. 

Results: Use cases that don’t provide any value to the actor. These use cases may not be derived from business requirements. Or they may be derived from business requirements but don’t contribute to the overall goal of the business requirement. 

Actions: Make sure every use case has a clearly stated goal that provides a benefit to an actor. Note that the actor that benefits does not have to be the primary actor in the use case. 

These are typical mistakes made when writing use cases. Many times the end result is a set of very long, very complex, and very technical use cases that provide very little benefit to end users or developers. Consider training your team on writing good use cases before just throwing them out the use case wolves. It will be worth the time and money spent to ensure use cases are providing the maximum benefit to your project.

(Reference: Use Cases: Requirements in Context by Kulak and Guiney)


 By Marcia Stinson 

Is your ship sinking?

Many years ago I worked on a huge project to upgrade a complex mission planning system to new hardware and a new language. Our requirements were simple (I can hear chuckling now). Simply make the new system work just the way the old system worked. Oh, and don’t forget to improve performance as much as possible. Oh, and don’t forget to improve the user interface to make it easier to use. And, oh yes, if you are working on a module that has a defect against it go ahead and correct that defect if it won’t take too much time. And, finally, oh yes, make sure the project is completed on time.

So the management team spent months preparing for this project. They looked at all of the software involved. They looked at resources. They got estimates for the time required to rewrite each piece of code. They assigned priorities to each task. They looked at resources and scheduled resources for each task. They created a project schedule. They created a huge spider chart that covered two walls showing the relationship and order of the tasks. That spider chart was so impressive when you came into the area and saw it. I’m sure you would think “Wow, they have this project under control and well managed.” The ship was ready to sail.

The project was supposed to be completed in a year. Would you surprised if I told you we didn’t complete it in a year. I forgot to mention that we had no requirements for the previous system. We were just working off of things by actually running the old system to see what it did. We had a couple of expert users who were checking things as we went to make sure it was acceptable. They were actually our testing team as it turned out. So at the end of the year we were 99% complete according the project schedule, spider chart, and all of the other metrics. The problem was that those metrics were all based off assigned values by the worker bees. Things were shown to be complete that weren’t actually 100% complete – they were close. Reviews were shown as complete whenever the meeting was held regardless of the follow up activities that were required. So everything looked great on paper. We all knew that wasn’t true. The ship had hit the iceberg.

Another year went by and we worked very hard. We were told to work harder and work smarter. But no overtime. Just get the job finished. We all worked hard. We ran into all kinds of issues with the new hardware. The issues kept bubbling to the surface but no one was really in charge of addressing the issues so they languished. The expert users kept insisting on enhancements that had not been agreed to and because we had to real requirements we kept trying to please them. And often their requests were in conflict with each other and there was no one to resolve that conflict. We usually ended up in a room with a lot of shouting going on. At the end of the year guess what? We were 99% complete again. The ship had sunk.
Management went ballistic, as you can imagine. The project manager kept insisting we just weren’t coding fast enough. That we were over analyzing. That learning a new language had slowed us down. This may have been true but the real problem was that we had no requirements to work from or to go back to when changes were made. In my mind that project was the epitome of chaos. That third year was the worst year ever. We worked ten hours days, often six or seven days a week, with no extra pay. I think we all just wanted to get this project done and finished.

So my question to you is this? Does everything look good on paper for finishing your project on time? If so, take a deeper dive into the requirements and make sure they are clear and traceable. Make sure the team knows what they are trying to do and who to take direction from. I think of the expression that “too many cooks spoil the pot”. Too many users involved in the development effort without defining the real requirements can spoil the project. Saying you have completed every milestone without having the deliverables to back it up is just delaying the inevitable. Good luck in steering your ship to a successful completion.

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

Why do I need a Requirements Management tool?

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

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