26 January 2012

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

20 January 2012

NHTSA-NASA Study of Unintended Acceleration in Toyota Vehicles

Today we would like to share with you the NHTSA-NASA Study on potential electronics-based causes for uninted acceleration in a popular vehicle. Plus, this analysis might be also interesting!

Enjoy your Friday!!

16 January 2012

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

12 January 2012

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.

03 January 2012

The Requirements Language Dilemma


Writing requirements has been a challenge for us for many decades now. Why is it so difficult? Well, one of the reasons is the challenge of the requirements language. We know we need to write requirements in a manner that can be read and understood by the reader. If we are writing user requirements, the reader is a business owner, end user, or stakeholder and the focus on writing in a “natural” language. The problem with a “natural” language however, is that is very imprecise and likely to be misconstrued or misunderstood. How do we bridge that gap?

I am amazed at the number of analysts I speak with that resist any kind of structure in their requirements writing. They appear to be quite happy with their unstructured approach that usually consists of descriptive paragraphs and sentences that imply many additional requirements. Their readers like this method they argue. The problem is that once these “requirements” are handed over to developers or systems analysts there is usually a lot of discussion back and forth to clarify what these requirements really mean.

I believe there is a compromise to be made here. Look at this slide from our Requirements Management Course.

Here are some tips to help bridge this gap.

  1. Write in active voice, making sure one of the actors is the subject of every sentence.
  2. Make sure every sentence is a complete and grammatically correct sentence with a subject, verb and predicate.
  3. Clearly specify what information is passed between actors.
  4. Maintain a consistent level of detail. (i.e. user requirements – an end user is the subject of every sentence, system requirements – a system is the subject of every sentence)

Good luck with your requirements and Happy New Year!

23 December 2011

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