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

Using Modeling during Requirements Elicitation

During elicitation requirements analysts are focused on understanding a CONOPS or Mission Statement and translating this to a more clear and concise format in the form of a requirements document. Modeling can reduce the time required for this effort and improve clarity and understanding. The following diagram illustrates the types of models that are frequently seen throughout the development lifecycle.

Models focused on the elicitation should be simple models that are non-technical in nature. These models should be easy to read and understand. Remember that their purpose is to clarify process flows or process narratives for non-technical end users and stakeholders. Moving immediately to UML or SysML type diagrams are too technical and usually too voluminous for stakeholders to read and understand.

The elicitation process consists of documenting high level capabilities, prioritizing the capabilities, and then using modeling to drill down and clarify how the capability will appear to the user. This technique can make the difference between unclear requirements and clear requirements that are validated and understood by the end users.

A good elicitation strategy is to begin with an outline of a basic process flow or use case with no alternate paths. Review this with the users and get agreement on this first. Once this is completed add alternate paths and document how they should be handled by the system. Do this for each step in the process flow. This will result in a very robust and clear set of requirements that capture details for handling alternate flows that may arise. Keep the language simple and clear and remove any information that doesn’t pertain to the flow itself.

This is the first step in understanding the user’s problem. Next is to figure out what the solution is to the problem!

By: Marcia Stinson