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.

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

IRQA Demo - Requirements Engineering Solution

IRQA Demo - Requirements Engineering Solution - Visure Solutions from Visure Solutions on Vimeo.

Requirements Management Tools – Today’s Trends

The market for Requirements Management tools looks heavily over-saturated today. And what is amazing is that new players are still constantly entering the market. However, just as quickly some of these players vanish from the market. Free trials seem to be becoming a standard practice for new tools and prices for web-based software are falling fast. There is a widening gap between the heavyweight, closed environment, local database traditional RM tools and the lighter and cheaper offerings which often also include free integrations with other software (including old RM tools). Requirements tools are becoming simple to download and install. This effort no longer requires complex database setup done by an administrator.

The trend towards a standard requirements interface is gathering momentum, allowing users to use requirements information across multiple tools, some of which are not requirements management tools.

Most RM tools are focused on either requirements definition or requirements management. It is important that potential customers understand the different between the two activities. Requirements definition is focused on gathering user needs and analyzing these needs to create a consolidated set of user requirements. This is just the beginning of the requirements effort. 90% of organizations today are still using Word to document their business and user requirements. Many requirements management tools today focus on providing a way to leverage existing requirements information that is provided outside of the tool, in particular a tool like Word. Other requirements management tools that are focused on this effort provide more functionality related to the elicitation process and provide methods to document actor and object names, create use cases, and document high level test plans.

Requirements management today involves very complex models to handle conditions such as multiple variations on the same basic project, reuse of components across projects, variants in reused components, and multiple release of each project. This complexity is not handled by many requirements management tools on the market today, especially those focused on the requirements elicitation activities.

IRQA is a state-of-the–art tool that has been able to meet many of the demanding needs of customers today. Although providing true requirements management support, it is not a heavyweight from an administration or cost perspective. It is simple to download and install and uses a standard database. The graphical view it provides to organize your project information is a new approach from a requirements management tool that allows users to easily visualize and create an information structure. If you are looking for a tool to handle some of the complex conditions mentioned in the previous paragraph then you should check out IRQA from Visure Solutions.

By: Marcia Stinson

Requirements Management – processes and tools

It’s no secret that professional requirements engineering solutions help improving efficiency when working with requirements. They also help minimizing the number of mistakes which would typically lead to costly corrections when found in later phases of the development lifecycle.

Therefore many companies are looking for such requirements engineering solutions. But unfortunately the same rule than for almost any other type of software tools also applies to requirements engineering solutions: a fool with a tool remains a fool…

The best-in-class requirements engineering solutions like IRQA from Visure Solutions are very flexible being able to support almost any kind of requirements engineering process. Of course, we – as a tool vendor – are happy to sell you some software but we are conviced that this alone won’t help you. Instead we want to help you being successful in using our products.

So, before purchasing a requirements engineering solution please make sure that you have a proper requirements engineering process defined with certain activities assigned to certain roles. Of course, we can also share our experiences with you in this area. If you know the detailed characteristics of your process it’s much easier for you to find an appropriate solution which fits the needs of your process.

I’m quite confident that IRQA will be your preferred choice…

By: Andreas Plette

The Importance of Requirements Management

Ask yourself these questions. Have you ever produced software that met all of the product specs but none of the customer’s expectations? Have you ever had to guess what information developers need from you to understand what you want? Without formal, verifiable requirements and AN EFFECTIVE WAY TO MANAGE THEM the result is usually a gap between what developers think they are supposed to build and what customers think they are going to get. (Karl Wiegers, Software Requirements, 1999)

I was reading this paragraph and what struck me was the portion you see in bold in the previous paragraph. For years we have been beating the drum about quality requirements. Everyone wants training on how to write them, how to structure them, how to test them, how to elicit them, how to make sure they are clear, complete concise…. and on and on. I’ve delivered a lot of these courses over the years. Students in the class nod and take copious notes about methods for ensuring requirements are clear and concise. But as I continue to teach these classes I have to ask the question. If you don’t manage those requirements after they are written, aren’t we missing some of the benefits of good requirements?

I look back at the reports we see from groups like Standish and Gartner. We are still seeing that nearly half of all projects are late and over budget, and that these are almost always tied to some kind of requirements issue. Yes, it is very important to elicit and specify clear and concise requirements that accurately reflect the user’s needs and wants. But that is just the first step in the requirements engineering process. The real work and effort comes in managing these requirements as development continues. In my experience there are very few organizations that really manage requirements. There is little or no traceability in these organizations. After all these years of knowing the importance of requirements management, why is there so little of it going on?

If you are in an organization where requirements are managed, then you probably snicker at these comments. I worked on a very complex weapon control system for many years. During that time I thought we were so behind in our requirements work. Actually, we were light years ahead of most organizations. We had full traceability from user requirements to code, a change management process, requirements were constantly updated as change requests were reviewed. We were doing this manually for a while until our customer insisted we had to implement a requirements tool.

I often hear excuses for not managing requirements – our project is so small it doesn’t matter, we don’t have time for those activities, we don’t have a tool. I’m beginning to think the management of the requirements is even more critical to project success and that it is time to focus on the requirements management activities. Requirements management must be an essential part of any project, no matter the size.

It’s Christmas – Let’s Not Talk About Requirements

Hopefully you have your shopping all done and are ready for the holidays. I admit I’m a bit of a procrastinator. But this year I got things done early and I’m all ready to celebrate. We’ve made plans for the family to get together. We know who is bringing what food for our big dinner. We follow the same process every year for opening gifts – youngest to the oldest.

Think about a different scenario. It is Christmas Eve and you are frantically running from store to store to buy gifts. They are picked over and you can’t really find what you want so you settle for just about anything. You rush home to prepare dinner. Only you find you don’t have many of the ingredients you need so you run back to the store. That’s picked over too. You can’t make the pie you wanted because you can’t find the ingredients. There are few turkeys left, only small ones, so you have to buy three small ones instead of one big one. You run home and work all evening preparing your meal. The next morning the family arrives, each one bringing a dish. And to your dismay you find you have four bowls of mashed potatoes and four bowls of sweet potatoes. No salad. No stuffing. Just your three turkeys and some potatoes. And no desserts. You open presents and there is not a big response to your gifts. Unfortunately there was nothing in those packages that the family really wanted. This scenario definitely is a result of no planning.

I’m sure you can see where this discussion is going. No planning. The results are questionable. We can probably get by with the end results. But it’s not ideal. Often it’s not even acceptable. Sometimes or family is forced to take what we give them, even if it’s not what they really wanted.

There’s always an excuse not to think about planning. I was trying to think of all of the excuses I have heard over the years. See if you recognize some of these.

I’m working too many hours to plan these activities.

The family doesn’t know what they want.

No one tells me what they would like for Christmas.

Our schedule doesn’t allow any time to plan – we just have to wing it.

We know it’s important, but who is really going to do the planning.

And so on it goes.

I said we wouldn’t talk about requirements and I haven’t mentioned them once (until this sentence). But without saying anything I’m sure you can see where this discussion is going. Since it is the Christmas week I won’t even add any additional points.

I will only say that I hope your holidays are better planned that we have talked about here. Enjoy the holidays with your families. And don’t think about requirements one time until you are back at work. Then you can think about the kind of scenario you want for your project. I wish the best for you and your family during this holiday season.

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

Best Practices – What does it really mean?

It is so interesting to me that everyone talks about wanting training in “best practices”. This term is often used to describe the kind of consulting we might provide as well. What does that really mean? I believe all of us have fed into the myth that best practices can be the basis for training individuals. Best practices are not trained, they are experienced.

If we compare the best practice approach to nature, we know that it not only the strongest but the most prolific species that survive. That’s one of the reasons it is so difficult to change processes in an organization. Think about that for a moment. The strongest and most prolific probably describe the majority of individuals you have in just about any group in your organization. I have seen this over and over in the System Engineering field. The strongest and most prolific engineers have often been doing their job for many years and have a specific way they do this job. Asking them to try new techniques and tools is often futile, as they don’t know how this is going to improve the already wonderful job that they are doing. Their practice is going to survive if we continue to shove a best practice approach at them.

So what do we do? Best practices start with our own personal experience. All of the books you pick up and read around best practices are about the author’s personal experience in some area, whether it is use cases, requirements elicitation, system engineering, testing, etc. At some point an organization decides that it needs a consistent process across the organization. There are lots of good reasons for doing this. So a group is formed to come up with a process that reflects these best practices. Since there are many best practices in the group, guess who usually wins? The strongest and most prolific. And the resulting best practice usually results in a compromise between the best practice group and those in the organization who perform this role. Studies indicate it takes about five years to actually role out this process across the organization. Then along comes the consultants who notice these practices. They may see an opportunity for business and so they get behind the practices that will lead to more business for them. They begin to show up in conferences and trade shows touting these practices and writing books. (Think about the Agile approach.) Because they are looking for business they are focused on the practices that will provide the most business for them. We are always in search of best practices so we don’t need to know how often it works, just that it CAN work. And so we continue to push that practice throughout the organization, hoping to realize all of the benefits that have been talked about over the years.

We must remember that best practices are based on hindsight. The best practices for your job are developed as you learned about that job. We can certainly learn from each other. That is not the point of this discussion. The point is that we need to base our best practices primarily on our own practical experience. We must be discerning in how we apply best practices to our jobs and our organizations. Just don’t accept best practices because someone wrote a book about it or spoke about it a conference. Research the practice and determine the environment in which they were fostered. Is this environment comparable to the one you are in today? Often there is little commonality. Choose the tidbits from the best practices that apply to you and your job and will provide real benefit to you. Start with slight changes and build on the practice as it is applied in your organization. Know where it has succeeded and where it has failed and learn from this. Remember that if you have strong and prolific objectors to the practice, you will need someone with a practical understanding of the practice to help the objectors see how this practice can help them. Listen to them and address their concerns. Don’t just ignore them and hope they will go away. They will not.

In other words, just saying the words “best practice” does not mean it will be a best practice for you.

By: Marcia Stinson

ReqIF – the devil is in the details… (part 2)

On November 3^rd the first meeting of the so-called “ReqIF Implementor Forum” took place in Germany http://bit.ly/vaatse

Visure Solutions and other major tool vendors in the requirements management space first tried to define naming conventions for those attributes that are provided out-of-the-box by the involved tools. We identified a couple of common system attributes:

• a unique identifier
• the user who initially created the requirement
• the time when it was created
• the user who did the last modification
• the time when the last modification was done
  
• and finally – probably the most important one – the attribute which holds the requirements text itself

For those attributes it was fairly simple to agree on a dedicated name and type to be used in the generated ReqIF files. It is important to note that we have not yet discussed how an importing tool shall handle all these information but it is obvious that neither of the tools is able to create a requirement on import and assign the original creation date found in the ReqIF file to the corresponding system attribute in the respective tool (of course a system attribute “Creation date” will automatically get the actual date of the import).

On the other hand having a commonly agreed attribute name for the requirements text helps the tool vendors to identify this information in a ReqIF file. The importing tool is then able to write this information into the appropriate system attribute of the tool.

Vendors not participating in the “Implementor Forum” will probably use (export) and expect (import) a different attribute name in the ReqIF file for the requirements text. It’s very likely that exchanging data with such an incompatible ReqIF implementation will result in a mess. It must be clearly stated that if a vendor claims to support ReqIF this does not necessarily mean that you can exchange data with other requirements management tools also supporting ReqIF. It is the main goal of the “Implementor Forum” to achieve compatible ReqIF implementations – at least for those tools represented in the “Implementor Forum”!

Apart from the common attributes we also took a look into the different tool-specific system attributes (out-of-the-box attributes not provided by all involved tools). IRQA for example provides a version number for each requirement which is not available out-of-the-box in other requirements management solutions. For these kind of attributes we have also defined appropriate names and types to be used in the generated ReqIF file – once again with the intention to help the other vendors to identify this specific kind of information in order to handle it appropriately.

Unfortunately we already found some tricky aspects which need further discussion. As an example we can talk about IRQA discussions: In IRQA any user may add comments to any of the requirements (as long as they can read them). It is very likely that these discussions contain valuable information that needs to be exchanged using ReqIF. But: a discussion entry is not just a string attribute. It consists of the user who created the comment, the date when the discussion entry was created, the version to which the comment is related and the comment itself. So, if we export to ReqIF shall we export only those discussion entries that are related to the current version of the requirement which is also exported? Or shall we export all discussions attached to a particular requirement? We may also decide to skip export of discussions…

On Nov 18^th a conference call will take place where the participants of the “Implementor Forum” will try to finally agree on the naming conventions of system attributes.

In addition we also started first discussions about test data since the tool vendors, of course, need some proven example data for testing their importing tool. We agreed that we will start with easy example files focusing on specific topics. The initial files will be provided by the participants who has driven the standardization of ReqIF. Later on each tool vendor will provide the same kind of example files generated with their respective exporting tool in order to allow other tool vendors testing the compatibility. For any of the test data provided somebody needs to check whether the files are ReqIF compliant.

Indeed, the devil is in the details…

By: Andreas Plette