Visure Solutions

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

2013-09-13T11:03:00.001+02:00

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

2013-09-10T11:23:00.000+02:00

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

2012-05-16T09:07:00.000+02:00

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?

2012-03-29T14:55:00.002+02:00

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?

2012-03-14T09:52:00.003+01:00

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?

2012-02-29T16:21:00.005+01:00

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

2012-02-15T12:59:00.003+01:00

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

IRQA Demo - Requirements Engineering Solution

2012-02-07T10:47:00.000+01:00

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

Requirements Management Tools – Today’s Trends

2012-01-26T09:35:00.003+01:00

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

2012-01-20T09:45:00.003+01:00

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

2012-01-19T11:54:00.005+01:00

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

Requirements Management – processes and tools

2012-01-16T10:44:00.003+01:00

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

2012-01-12T17:11:00.001+01:00

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

2012-01-03T18:43:00.002+01:00

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.

Write in active voice, making sure one of the actors is the subject of every sentence.
Make sure every sentence is a complete and grammatically correct sentence with a subject, verb and predicate.
Clearly specify what information is passed between actors.
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!

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

2011-12-23T12:08:00.003+01:00

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

Asking Great Questions – Requirements Elicitation

2011-12-07T17:02:00.004+01:00

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

Do we really need Requirements Management?

2011-12-05T09:07:00.002+01:00

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

Risk Analysis in Requirements Engineering: FMEA

2011-12-01T10:22:00.003+01:00

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?

2011-11-30T11:43:00.008+01:00

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

Practice Makes Perfect – Requirements Engineering Training

2011-11-23T11:04:00.004+01:00

When I was young my mother decided I should take piano lessons. I was five years old and barely knew my ABC’s. My teacher was an older woman who sat down my first lesson and played Beethoven’s Moonlight Sonata for me. I was so impressed. I wanted to play that piece right away. An impossible goal, of course.

There was so much I had to learn before I could play that piece. I started with one hand (one hand, are you kidding????) and learned three notes on my first lesson. Then three notes on the left hand. Then five notes. I remember thinking this would take forever. And so on. It was many years of learning and practice before I was able to play Beethoven’s Sonata.

There were some key things I had to learn to do. First, I had to learn how to hold my hands properly. Then I had to learn to read music – a few notes at a time. Then I had to learn how to read the music and then play it. And, above all, I had to practice. I practiced at least an hour every day, more in the summer. And still it took five years for me to play that piece. My teacher was instrumental in that process. She taught me techniques. She corrected me when I made a mistake. I could not have learned to play the piano without her.

So let’s tie this to Requirements Definition and Management. Asking someone who’s never written or managed requirements to follow a robust and complex requirements process is like asking that five-year-old to play Beethoven’s Moonlight Sonata. And since we often don’t provide any training or mentoring, let’s ask them to learn to play that piece on their own. That’s what we are doing when we throw our analysts into a complex requirements process.

I suggest we consider training our analysts. Let’s stop thinking we all just “know how to do our job”. It isn’t true. We can learn to play that piece on our own. I would suggest instead of taking five years, it would have taken me ten years on my own. And so it is with our requirements engineers and analysts. We can let them learn on their own. Or we can give them some training, mentoring, and time to practice.

Of course, key to making this work (no pun intended) is having some kind of process defined that we use to train our analysts. I used to hate that “process” word, but it is important. Here are some suggestions for turning your new requirements analysts into expert requirements analysts quickly.

Provide training for your analysts around your specific process, using your requirements and deliverables, so the training is more real.Generic classes around requirements definition and management are great, but they must be in line with the processes you are following in your organization.If you are working with an outside consultant, expect that there will some effort in customizing the training for you.But it will be worth the investment.
Assign a mentor to your new analysts.Let someone who has “been there done that” and has the wounds and scars to prove it help the new analyst and show them the ropes.This will help eliminate that “tribal knowledge” thinking.Let them assist in elicitation sessions, review requirements documents with the analyst, and be a resource for them.
Let the analyst practice. That may not seem too practical. But don’t start a new analyst on a project that is critical to the company. Or one that has so much history and controversy around it that it will be difficult to move forward. Let them “practice” on a simple and well understood project to get their feet wet.

I believe the following statement is true.

“Good analysts are grown, no trained.”

Let’s grow some good analysts.

By: Marcia Stinson

Best Practices – What does it really mean?

2011-11-15T10:51:00.004+01:00

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)

2011-11-10T17:51:00.003+01:00

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

The Mystery of Requirements

2011-11-08T15:37:00.004+01:00

Many times in writing or reviewing requirements we tend to be a little “sloppy” in our writing. We need to remember that are not writing a mystery. What are some qualities of a good mystery novel?

There is an underlying theme to the mystery.
There are a lot of great characters involved.
There is a clear setting where the story takes place.
The final few chapters hold the climax of the story.

In other words, the author gives us clues all along, but it isn’t until the last few pages that we suddenly understand what the author has been trying to tell us all along.

Let’s take this approach with requirements. What makes requirements a mystery?

There is no underlying theme. In other words, there is no clear reason, business or otherwise, why we are even doing this project.
We get some of the characters involved, but we tend to miss some too. Making sure we have included everyone who is impacted by the project in any way is an important component.
We’re not sure where the story takes place. To make a comparison, we don’t know where the product will be deployed or who will be using it. We need to know the setting.
We are not persistent in understanding all of the clues the users give to us. There are lots of clues if we just pay attention. Users and stakeholders give us clues in many ways. Sometimes the clue may be in the way they respond to our questions in a nonverbal manner (i.e. rolling their eyes, crossing their arms, etc.). They may state assumptions about what they are thinking, yet another kind of clue for us. Sometimes a clue may lie in unspoken requirements that we have to try and get the users to verbalize for us. And sometimes the clues are in the form of a solution. When the users give us a solution they are really giving us a clue that they have a problem they are trying to solve. We must strive to understand what that problem really is.

The end of a mystery is exciting and gets our blood moving. We’re not sure until the last few pages that we really understood everything. If we manage projects in the same way we are in trouble. Software development should not be a mystery to us. We can’t wait until deployment to make sure that we solved the problem correctly. We want our requirements to be as clear and correct as possible from the beginning.

So here are some simple guidelines for writing requirements in a simple and concise statement, and removing some of that mystery.

Every requirement should be a complete sentence. (i.e. a subject, verb and predicate with a period at the end) Remember our old English classes when we actually diagrammed sentences?
Every requirement should describe clear success criteria. (The user shall be able to view the Audit Log Report.)
Every requirement should state a single action and objective. Watch out for excessive use of “and” and “or”. For example:(If is the last Friday of the month and the payment is due on the 31^st, and if the 31^st is the last Friday of the month, then submitting the payment on that day after 6pm eastern time will result in a late payment.) I challenge to understand that one!
A requirement should not have an escape clause. (The System shall determine the number of login attempts except when the user has clearly entered an incorrect username.)

Let’s make sure our requirements are not a mystery!

By: Marcia Stinson

ReqIF – the devil is in the details…

2011-11-03T14:44:00.003+01:00

Once upon a time there were some German car manufacturers which were convinced that using Word and Excel for managing their requirements is not feasible. So, they started using a professional requirements management solution. But collaboration with dozens of suppliers becomes a nightmare. Their approach was trying to force the suppliers to use the same tool. But who likes to be forced to do something? It gets even more complicated if many manufacturers (using different tools) want to collaborate with many suppliers and those need to collaborate with other suppliers. Today even the manufacturers themselves start working together in some dedicated areas…

The only possible solution: they all need to agree on using the same tool in probably the same version. Realistic? No!

So, the major German car manufacturers and suppliers met in order to discuss alternative ways to improve collaboration across company borders without losing the benefits of professional requirements management solutions. The Requirement Interchange Format (RIF) was born in a first version… The overall idea of RIF is allowing requirements data exchange between different tools.

First implementations were developed and it turned out that RIF did not work as expected. Over time RIF was improved and finally - to get more acceptance on both the tool vendors and the users side – standardized by OMG. Since there was a naming conflict at OMG RIF was renamed to ReqIF (keeping its meaning). The final OMG approval on ReqIF 1.0.1 happened in April this year. http://www.omg.org/spec/ReqIF/

But why the hell all the major players in the requirements management domain have not implemented ReqIF yet?

Because it will still not work between different tools if each tool vendor just implements ReqIF on its own. The standard just provides an XML schema where tool vendors put their data in. This data may contain attributes with a certain name and value. Unfortunately the different tools typically use specific attributes to store, for example, the description of the requirement. Let’s assume tool A calls this attribute “description” and tool B uses “requirements text” for the same kind of information. The ReqIF export from tool A will probably contain the attribute name “description”. If tool B tries to import this ReqIF file it does not know that “description” should be mapped to “requirements text” in tool B. So, tool B would probably create a new text attribute “description” to store the data there instead of storing the data in “requirements text”.

This is just a very simple example. I could imagine far more imcompatibility issues when exchanging data between different tools. Just think about a situation where tool A supports a certain data structure which is not supported in tool B.

To avoid as many of these issues as possible Visure Solutions - among other major tool vendors - agrees on participating in a follow-up activity of the ReqIF standardization group which is called the “Implementor Forum”.

In this “Implementor Forum” the tool vendors will try to find a harmonized glossary for the individual data models of the different tools in order to provide implementations afterwards which are compatible to each other. Right now (November 3^rd, 2011) I’m currently attending to the first meeting …

That’s why these major tool vendors have not yet implemented ReqIF. Before implementing we will capture and analyze the requirements… J

Stay tuned. I will give an update about the progress next week.

By: Andreas Plette

Requirements Management in an agile world

2011-10-31T13:42:00.008+01:00

Since a couple of years agile development is a mega-trend. One of the most famous processes in the agile world is Scrum. In theory, Scrum does not need any software tools for managing “epics”, “user stories”, “product backlogs” or “sprints”. Simply speaking you just need a whiteboard and lots of post-it^®. But what if your Scrum team is distributed? Or if you want to benefit from the work done in the past? Then it would be useful to have the data stored somewhere…

Why not using a flexible requirements management solution which is capable to enforce any kind of process. Let’s take the following process as an example for an implementation of a Scrum process:

The Product Owner will describe “epics” and “user stories” derived from them (traceability!) where “user stories” will automatically be included in the “product backlog” getting some product backlog specific attributes (e.g. delivery date, priority, assigned team). Each Scrum team can easily find the “user stories” assigned to their team and decide which stories they want to deliver in the next sprint. As soon as the story is assigned to a dedicated sprint (but not before) the scrum team is allowed to derive individual “tasks” which are assigned to certain team members. Each “task” will also have a status (to do à in progress à done).

Using a professional requirements management solution will allow:

the product Owner to see which "user stories" is/was implemented in which sprint:

the Product Owner to see the current status of the tasks derived from the "user stories" for a particular sprint:

The Scrum team member to focus on his tasks:

Professional requirements management solutions allow to define role-based views on the data which improve efficiency tremendously.

Furthermore generation of various reports (e.g. burndown chart) from the actual data is just a single click – if not done in batch mode. Those reports might be in HTML format to include them in the intranet.

By: Andreas Plette