Compliance to standards

Today there is almost no industry not being penetrated by standards and regulations such as IEC 61508 and its derived standards for the different industries.

Those standards are typically provided in PDF format and contain often hundreds of pages from which only a certain subset might be relevant for a specific project. For another project a different subset of the standard might be relevant. So how to prove compliance efficiently with such a standard if there is no way to:

• Trace the project requirements back to individual statements of the standard?
• Check if all relevant statements from the standard are covered in the project requirements (how to identify quickly the relevant aspects contained in a huge PDF and whether they are already covered by the project?)?

Appropriate solutions by Visure Solutions may help here: first of all you would need to import the relevant part of the standard into a requirements management solution where each statement is its own referenceable unit. Of course this should be done in an automated way (who really likes to copy/paste thousands of sentences from a PDF to some other tool?). Then you can use the capabilities provided by such a tool to create relationships between individual statements of the standard and the requirements derived from them, proving compliance to the standard by using the numerous capabilities provided by requirements management solutions for analyzing traceability and coverage

But what if you need to see the details of a statement in the original PDF?

Just navigate there!

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