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

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!!

Software Fails...

We would like to share with you a recent fact written by Matthew Humphries, check it out!

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.

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!

Asking Great Questions – Requirements Elicitation

As part of the elicitation process, it is critical that we ask the right questions. When I hear someone say “The customer doesn’t know what they want,” I tend to cringe. I think the customer knows what they want. They may not know how to express that to us. Our job is to ask the right questions so we can help them explain to us what it is that they want. Sounds simple, right??

Here are some tips to getting to those GREAT (not just good) questions.

1. Keep an inventory of “Great Questions” I believe that successful requirements elicitation interviews begin with preparation. Many analysts think they can just go sit with a user and figure out what they want. That is not the case. Analysts need to research the problem domain and think about the questions they need to ask. The primary difference between expert analysts and novice analysts lies in the ability to recognize situations and apply the proper tools (i.e. questions) that are appropriate for the situation.

Experienced analysts tend to ask similar types of questions – they know they get the best results. When conducting an interview watch for instances where a particular question or specific phrasing of a questions works well in getting you the information you need. When that happens write it down. Add to the list as you become more experienced. Having these questions available makes preparing for interviews quicker. These questions, or versions of them, will server you will for nearly any project. Put them in your “toolbox” of questions.

2. What “points of pain” are we trying to solve? This is a great question for getting to the real business problem. We often get into projects assuming we all understand why we’re doing it. Let’s make sure. Let the user describe the pain he is hoping will be alleviated by this project. I asked a user this one time to have them respond that they had no idea what pain this project was supposed to alleviate. Not a good scenario. An alternative to this question is to ask what user this project need will fill.

3. What would happen if we did not implement this project? This kind of question can help get a feel for the criticality of the project. If the users do not feel it is critical, maybe we should rethink why we are using precious resources at this point in time for this effort.

4. What does success look like to you? This helps you understand the stakeholder’s vision for this project. What is the most important result of this project to you? Consider creating a checklist for success factors and order them in order of importance.

5. Who will benefit most from this project? This will help identify key stakeholders and users. This can provide a starting point for identifying actors for high level use cases or user stories.

6. Close every interview by asking if there is anything else that should be covered. This gives the interviewee an opportunity to express other thoughts or opinions that are important to them. This almost always uncovers a couple of new items of value.

This is just a starting list of potential questions. Add to your own list of great questions and share them with other members of your team. Remember the focus of elicitation is to get to the “essence” of the system – why it exists. Good luck!

By: Marcia Stinson

Risk Analysis in Requirements Engineering: FMEA

In a couple of industries like Automotive, Aerospace and Medical Devices Risk Analysis becomes more and more important because lots of standards and regulations require Risk Analysis for safety critical systems. In many cases the manufacturer of such a safety critical system is forced proving that they did Risk Analysis in a proper way.

FMEA (Failure Mode and Effects Analysis) is one of the most famous techniques for analysing risks. In FMEA an interdisciplinary team derives risks from the requirements which are then evaluated in a structured way. For each risk three values are specified:

• Severity
• Occurence
• Detection

The Risk Priority Number (RPN) is then calculated by multiplying these three values. If the RPN is lower than a certain threshold the risk is seen as acceptable and no further actions need to be taken. If the RPN is too high additional actions must be taken to either decrease the probability of occurrence or to increase the probability of detection by the system.

Whenever an action was defined to reduce a certain risk a re-evaluation needs to be done. If the RPN for risk + action is still too high another action must be defined.

While preforming Risk Analysis we obviously create different types of information which are related to each other. So, why not using the requirements management solution with its dedicated support for managing such relations not only for the requirements but also for Risk Analysis?

Using the traceability capabilities of such a solution eases up approvement processes with certification authorities tremendously.

And if you need to create a nice looking report for the certification authority, just click a button (or generate them in batch mode while you relax at home…):

Life could be so easy…

By: Andreas Plette

What is a requirement?

Whatever kind of system, software, product or service you would like to offer to the market all your efforts are based on requirements to be fulfilled. Indeed, this is not new. Most of us are writing requirements since decades. But do we really know what a requirement is?

There are almost as many definitions out there as books available about Requirements Engineering. But do these definitions really help in our daily work?

A couple of weeks ago I had the pleasure to participate in a workshop about requirements methodology. At the beginning we did a small exercise. We got the following text frament – taken from a real-life example (!) - and we were asked to count the requirements regardless whether they are “good” or “bad”:

Sounds like a simple question. But: although most of the participants had several years of experience working with requirements we got an interesting result (the constructor wrote down the answers of the individual participants):

Why that?

Of course, each participant has its own experiences and knowledge about the system to be build which highly influences the way they read the document. So, you cannot expect to get a single answer…

Then we started to analyze the given text sentence by sentence trying to formulate requirements with better quality based on two of the most important characteristics for a “good” requirement:

• You must be able to implement the requirement
• You must be able to verify that the implementation fulfils the requirement

Using these quite simple rules we came to the following improvement (which still may not be perfect):

From this example you can see one of the major drawbacks when using word processing tools for requirements: Authors tend to provide justifications for certain requirements in subordinate clauses (e.g. 3 is the justification for 2). Then it may happen that they introduce redundancy (e.g. requirements 2 and 5 in the example above) which makes it difficult to maintain these documents. Apart from the implicit relations the author has “created” using subordinate clauses there are of course more relations between the different requirements we identified above. If you try to represent these relations in a more structured way you may get the following [please do not use a word processing tool for this… = ) ]

So, finally we identified requirements from four different abstraction levels within the first three sentences of the original document!

Think about it…

By: Andreas Plette