Defining Requirements - Service V Model approach ITIL® v3

Vijay Reddy

Last updated October 26, 2016

16619 Views

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.

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:

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:

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

About the Author

Vijay Reddy has several years of experience in delivering and managing IT Services, Software Development, Product and Production Support and has expertise in IT strategy consulting, Governance and risk management, IT security, cloud computing and implementation around large customer accounts, managing the delivery of large outsourced IT Service and software development engagements and in depth understanding of deal structures and delivery options and models. His experience has been across diverse industry segments – Banking, consumer products, Retail, Oil & Gas and Hospitality. Vijay is an APM Group International certified and accredited Project Management (Prince2®), Programme Management (MSP®) and IT Governance (COBIT5®) Trainer, Exams Proctor, Supervisor and Invigilator. He is also EXIN accredited trainer for ITIL – 41 credits (All Modules leading unto expert), ISO 20000, ISO 27002, Lean IT and Cloud Computing.