Diaverum had different types of requirements driving different aspects of their project and of the development of their system. As a result, they had different regulatory requirements in the different countries, performance aspects and functional requirements from the users. User training is expensive, which is why user friendliness and learnability are important requirements on systems with many users.

Most standard methods totally lack a full coverage regarding requirements analysis covering both functional and non-functional requirements. Most project models also lack structure regarding what requirements that drives the different disciplines of the project. Another problem is that even if you work with your requirements specification there is often no obvious traceability towards the actual properties of the resulting system you have developed. Most organizations lack a structured way of capturing and maintaining the full picture.

In our case project we introduced the concept of “system properties”. A required system property corresponds to a requirement, but the system properties also have the role of describing the resulting system. In this way it became natural that the requirements wasn’t just an input to the project but also something the project delivered, which was a system with a set of well-defined properties. In order to cover all aspects of system properties we used ISO9126 to identify the different categories of system properties. By using this standard we could ensure that we covered all aspects. We could also use it as a check-list to ensure if certain properties where applicable or not.

ISO9126 defines a set of categories: functionality, reliability, usability, efficiency, maintainability and portability. Each category is then divided into a set of sub categories. The next step is to decide what sub categories are relevant for our system or our project. Then we need to define how we can measure and verify each property and also what aspects of the project that are affected by a certain property. Finally we will try to capture the requirements for each property. During the project we continued to refine the system properties and verified them. As an output we delivered a verified set of system properties that described more or less all aspects of the system.

Example: In our case we identified a set of required functional properties in the category of suitability. This is the category where we capture most requirements on the system in order to support the business processes. These requirements where captured by using cases and verified mainly with explorative testing by the test team. The test team was responsible not only for verifying the actual behaviour towards the required behaviour, but also to ensure that the descriptions reflected the functionality of the resulting system.

Up-front in the project we felt secure that we covered all the aspects of system requirements.

It was clear up-front for all project members how and where we would capture the different types of requirements.

The business analyst, users, developers, testers and QA all worked with the same source.

Aspects such as “How can we verify this property?” was addressed very early in the project. For instance, it was obvious already in the beginning of the project that we needed to simulate the network behaviour in the different clinics in terms of latency and bandwidth.

We saved a lot of time since we used the same documents for specifications, descriptions and hand-over material.



Please feel free to share