Defining Requirements - Service V Model approach ITIL® v3

Service V Model is a concept that is raised in the Service Transition volume of the new ITIL® Version 3. The Service V Model is a unique concept that provides a path to follow with regard to defining the requirements for a service package, designing the package, building and then testing the package. The model provides baseline points along the path that are used a checkpoints to ensure that what is being designed, built and delivered is actually what was required. Each step on the path also has specifically named outputs that should be visible.

Preparing for ITIL? Take this test to know where you stand!

The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. Within each cycle of the iterative development, the V-model concepts of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trial and assessment. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. During each phase of software development, thought is already given to the corresponding tests. For instance, during the definition of the service requirements, the corresponding acceptance tests are already written and signed off.

The advantage of the V-model is that by writing the tests at the time of specification errors in the specifications can be detected in an earlier phase, avoiding costly reworks later on. Additionally, testing happens at different levels, first component testing, then package testing, system testing etc., again leading to early detection of errors.

Using techniques such as the Service V model for Service Validation and Testing provides a framework to help organize the levels of Configuration Items that are needed and the associated testing and validation activities within and across stages of the change. The Service V Model is a concept of establishing acceptance requirements against the various levels of requirements that apply in order to justify release to the customer for trial and assessment. The left hand side represents the specification of the service requirements down to the detailed Service Design. The right hand side focuses on the validation and test activities that are performed against the specifications defined on the left hand side, and there is direct involvement by the equivalent party on the right hand side. It shows that service validation and acceptance test planning should start with the definition of the high level requirements. It also describes that the person/group or sign off on the requirements on the left side should be involved on the right side to accept that the requirements have been met.

The actual tests required at each level should reflect the approach to risk and level of confidence that is required for the service change being transitioned. There are many frameworks and sources of guidance focused specifically on testing e.g. Test Management Approach (TMAP) that provide more details about the specific types of testing activities that can be performed. These normally include:

• Usability testing
• Accessibility testing
• Process and procedure testing
• Knowledge transfer and capability testing
• Performance, capacity, and resilience testing
• Volume, stress, load, and scalability testing
• Availability, backup and recovery testing
• Security testing
• Logistics, deployment, and migration testing
• Build, packaging, and distribution testing
• Operability and maintainability testing

Test Strategy

A test strategy describes the overall approach to organizing testing and validation, including the allocation of the enabling resources required. It may apply to the whole organization, a set of services or a single service. The typical contents of a test strategy document include:

• The purpose, goals and objectives of service testing and validation
• Scope and organizations
• Applicable standards, legal and regulatory requirements
• Service Management policies, processes and practices applicable to testing
• Test models used
• Test process activities (planning and estimation, documentation, control, execution etc)
• Test metrics
• Service Provider interfaces
• Test criteria
• Roles and responsibilities
• Environment requirements
• Deliverables

Test Models
A test model describes a test plan, the scope of a test and the test scripts that define how each element will be tested. It ensures that testing is a repeatable process and that the defined deliverables are achieved. Test models should be structured so that:

• There is traceability to the initial design requirements and criteria
• All activities can be measured and audited
• That test elements can be reused or changed Service V Model is an excellent example of a test model used according to the different levels of testing and validation that apply

Why should one use Service V Model?

• All of your beautiful plans become ugly at some point. So you need reliable and proved standards to well manage the deployment of your applications or new and changed services.
• In other words, you can use the same standards again and again; it can be applied in the same way across different suppliers and/or clients you may have. It is easy to fit and explain to suppliers and clients.
• The Service V-Model helps to mitigate risks when implementing something new in your infrastructure. So you can have fewer issues caused by unpredictable risks.
• It helps the team document the customer’s requirements in a standard format; it helps understand what your customers really want; and helps you in estimating and funding for your business case.
• The Service V-Model helps managing the customer’s expectations. If some of your clients requirements are changed after you have already started your design and build; you have tools to negotiate and tell your clients how long a ‘Test’ will take to place or how long it will be delayed.

[Click here to download the complete guide on ITIL Certification]

Hope that helps. If you've got any questions, feel free to ask them.