Service Design Technology related activities Tutorial

4.1 Service Design Technology related activities

Welcome to Learning Unit # 4 of ITIL Lifecycle Intermediate Service Design Certification Course by Simplilearn! One of the key ITIL principles is ‘to focus continuously on meeting business requirements thus enabling the business achieve its objectives and outcomes’. In this direction understanding the business requirements in the right way and developing service solutions that fit these requirements is the foremost responsibility of IT service management. Requirements Engineering, Data and Information Management and Application Management are some of the key elements for developing and delivering relevant and efficient IT services. Let’s look into the syllabus in the next slide.

4.2 Learning Unit 4: Syllabus

Syllabus The objectives of this learning unit are to cover: • The knowledge, interpretation and analysis of service design principles, techniques and relationships and their application to the design of effective service solutions. • Requirements engineering in the design process and utilising the three types of requirements as identified for any system; functional, management and operations and usability. • The design of technical architectures for data and information management, and application management. In the next slide we will learn about the requirements engineering.

4.3 Requirements Engineering Types

Requirements Engineering We know that all the services provided by IT are focused towards enabling the business to achieve its outcomes and objectives. This emphasises the fact that IT service providers and organisations should ensure that the business requirements are collected, validated and fed into the service lifecycle to transform them into reliable and efficient services that support business processes and outcomes. Requirements engineering is the process of understanding and documenting the requirements of the business, users and all other stakeholders, and ensuring traceability of changes to each requirement. In this module we shall be focusing on the requirements engineering in relation to the technology that would be used for designing, developing and delivering the services. First let us discuss the ‘types of requirements’. Requirements may be categorised into three types – Functional, Management and Operational and Usability requirements. •Functional requirements are the elements necessary to support a particular business function, business process or removal of a customer or user constraint. Basically, they represent the ‘Utility’ aspect of a service and represent the tasks or functions that the component is required to perform. System context diagrams, case models, data flow diagrams and textual descriptions are the tools that can be used for gathering functional requirements. •Management and operational requirements are the non-functional requirements which address aspects such as responsiveness, availability and security of the service and service components. These requirements are mainly concerned with the quality or warranty aspects of a service. •The different categories of management and operational requirements are: •Manageability requirements •Efficiency requirements •Availability, reliability and maintainability requirements •Capacity and performance requirements •Security and continuity requirements •Operability and controllability requirements •Measurability and reporting requirements •Usability requirements relate to the users’ expectations regarding the access to and use of the service. These requirements mainly address the ‘look and feel’ and ‘ease of use’ aspects of the service from a user perspective. The usability requirements also represent the quality aspects of the service and form a key input to planning and designing test plans and test cases. We’ll continue with the requirements engineering in the next slide.

4.4 Requirements Engineering

Requirements Engineering • The value of a service is generated during the service strategy, service design and service transition stages and is actually realised in service operation stage. The customers and users start using the service to perform business processes and activities and accomplish the desired outcomes. The users are the key stakeholders in the utilisation of the service and their requirements and views form the key components of the overall service requirements. • Users have formally defined roles and activities as user representatives in requirements definition and acceptance testing. People with adequate knowledge, skills and commitment should be identified for participation in the requirements gathering stage. • They should be actively involved in identifying the functional, management and operational, and usability requirements of the service, and also in: • User training procedures and facilities; and • Support activities and Service Desk procedures. In the next slide we will learn about the requirements investigating techniques.

4.5 Requirements Engineering Investigation techniques

Requirements Engineering • Requirements investigation techniques • Gathering, validating, documenting and finalising customer and user requirements is a complex process and requires a great amount of attention to detail. That’s where requirements engineering plays a significant role in adopting a systematic approach in establishing the right level of information required for designing and building the services. A number of techniques may be used to capture the business and customer requirements. These stakeholders may sometimes not be clear in presenting or defining the requirements. Hence, investigation techniques will have to be adopted to solicit and document the requirements. We shall now briefly discuss these techniques. • Interviews are one of the best key tools for information and requirements gathering. The results are far more effective when the interviewer prepares thoroughly and solicits the right type and level of information. While there are many interviewing structures that may be used, the classic questioning structure of ‘Why, What, Who, When, Where, and How’ provides an excellent framework for preparing for interviews. • Gathering requirements through workshops is another good technique that may be used. Workshops provide a platform for gaining a broad view of different perspectives from the participants; debate and agree the view points; gain consensus and buy-in; and normally a much speedier way of requirements gathering. • Observation involves watching the specific tasks performed by the users. The presence of the analyst in the workplace for obtaining information helps in getting a much better understanding of the tasks performed as well as problems faced by the users. It also helps devise solutions that are more likely to be acceptable to the business. • Protocol Analysis is the approach where users describe each step of the tasks as they execute them. This enables capturing requirements in a more realistic manner and from the users who are actually responsible for executing the tasks. • Shadowing involves following a user and observing the tasks performed for a period of time with respect to a particular job. It would be useful to shadow the end-to-end tasks executed by the user and pose questions where ever required. • Scenario Analysis involves tracing the course of a transaction from an initial business trigger through each of the steps needed to achieve a successful outcome. It also involves identifying alternative paths of achieving the outcome or completing the transaction. It further translates into developing good test scripts. • Prototyping is the technique of eliciting, analysing, demonstrating and validating requirements. It practically shows the user how the new service might work and the ways in which it can be used. It helps clarify the requirements in the initial stages itself and also encourages users to come up with additional requirements. • The other techniques include: • Distributing questionnaires and requesting the users and business representatives to fill in their responses. • Verifying the ‘special purpose records’ maintained or asked to be maintained by the users recording a specific issue or task. • Activity sampling is a quantitative form of observation wherein only a small set of the activities or users are observed and information gathered instead of all the activities or entire user group. In the next slide we will learn about the problems with requirements engineering.

4.6 Requirements Engineering Problems

Requirements Engineering • Requirements Engineering is not an easy job and getting the right requirements from all the relevant stakeholders is even more difficult. Tight timescales, non-availability of key users and business representatives, inability to articulate the requirements and not understanding the impact at later stages in the lifecycle are some of the challenges faced by Requirements Engineering. Studies and experiences from various IT project failures have led to the following findings: • A large proportion of errors, more than 80percent are introduced at the requirements phase; • Very few faults, less than 10percent, are introduced at design and development phases; • Most of the project time is allocated to the development and testing phases of the project; and • Less than 12percent of the project time is allocated to requirements engineering activities.

4.7 Requirements Engineering Problems

The general problems and issues faced by requirement engineering are: • Lack of relevance to the objectives of the service; • Lack of clarity or ambiguity in the wording; • Duplication of requirements or conflicts between requirements; • Requirements that assume a solution rather than stating what is to be delivered by the service; • Uncertainty among users about what they need from the new service; • Users omitting to identify requirements; • Inconsistent levels of detail; • Failure to include requirements from service provider stakeholders such as service operations and support staff; • Failure to include non-technical requirements critical to success of the service such as requirements for training, documentation, communications and marketing; and • Requirements creep – the gradual addition of seemingly small requirements without taking the extra effort into account in the project plan. Let’s learn about documenting requirements in the next slide.

4.8 Requirements Engineering Documenting requirements

Requirement Engineering • Documenting requirements: The end product of the Requirement Engineering process is a Requirements catalogue. The requirements catalogue will consist of each individual requirement documented in a standard format and may be supplemented by other documents or specific models. • All requirements should be scrutinised for proper classification and completeness and must be reviewed by business representatives before they are formally entered in the requirements catalogue. A checklist containing the following questions may be used to check the correctness and completeness of the requirements. • Are the requirements, as captured, unambiguous? • Is the meaning clear? • Is the requirement aligned to the service development and business objectives, or is it irrelevant? • Is the requirement reasonable, or would it be expensive and time consuming to satisfy? • Do any requirements conflict with one another such that only one may be implemented? • Do they imply a solution rather than state a requirement? • Are they atomic, or are they really several requirements grouped into one entry? • Do several requirements overlap or duplicate each other?

4.9 Requirements Engineering Documenting requirements

Requirements Engineering Let us look at a few more concepts relating to Requirements Engineering. • As discussed earlier all requirements should be logged in the requirements catalogue. It is the central repository of the business and user requirements and should form part of the service pipeline within the overall service portfolio. It should be the single source of complete information on all requirements for new or changed services. • A Requirements Template: Each requirement, after scrutiny and review by business representatives, should be documented using a standard template. Each requirement should have a unique Requirement ID and should also capture other related information like source, owner, priority, description, related documents and business process, and justification. • Full requirements documentation: A good requirements documentation should include a glossary of terms defining each term used; a scoping model; the requirements catalogue and supporting models. Changes to the finalised requirements documentation should be managed and controlled by seeking complete details and confirmation from appropriate business representatives. Let’s discuss requirements and outsourcing in the next slide.

4.10 Requirements and Outsourcing

Requirements and Outsourcing • Requirements analysis is an iterative process. The requirements will change, due to various reasons, during the period the application and service are being developed and requires user involvement throughout the development process. • The suitable service solutions meeting the requirements can either be purchased off the shelf, developed in-house or outsourced. In present day world dependence on external suppliers is increasing. The typical approaches to contract for the development of IT systems are: • Low-level requirements specification: In this approach the boundary between ‘customer’ and provider is drawn between the detailed requirements specification and any design activities. The requirements are specified in detail giving the supplier a very clear and precise implementation target. • High-level requirements specification: The customer/provider boundary is between the high-level requirements and all other phases. The provider is responsible for building, testing and deploying the applications and services within the scope of the contract and the customer is responsible for testing the delivered service against the business requirements. We will learn about data and information management in the next slide.

4.11 Data and Information Management

Data and Information Management Data/information management is concerned with how an organisation plans, collects, creates, organises, uses, controls, disseminates and disposes of its data and information. Data is an important asset and in combination with other resources and assets is essential for the achievement of the aims and goals of the organisation. Let us now discuss the various aspects of Data and Information Management. • Managing data assets: Data and information management involves establishing policies and standards to handle the data pertaining to services. It also includes data/information asset management which helps in adding value to services, reducing risks and costs and to stimulate innovation. On the contrary, lack of an effective data management process will result in a number of issues like people collecting data that is not required and failing to adhere to regulatory requirements. • Scope of Data Management: It is important that the scope of Data and Information Management is clearly defined. At a minimum it should cover four important areas – Management of data resources; Management of data and information technology; Management of information processes; and Management of data standards and policies. • Data Management and the Service Lifecycle: The best approach to data and information management is to adopt the lifecycle approach. It helps in understanding the use of data in business processes across the service lifecycle. • Supporting the Service Lifecycle: Data and Information management should be aimed at providing the required level of support to various lifecycle stages. During requirements and initial design, data management can assist design and development teams with service-specific data modelling. Similarly, during detailed design and development, the data management team can provide technical expertise on database management systems and on how to convert initial ‘logical’ models of data into physical, product specific, implementations. • Valuing data: Data and information are organisational assets and have value. Determining the value of data can be done through: • Valuing data by availability - that is to consider which business processes would not be possible if required or specific data was unavailable, and how much that non-availability of data would cost the business • Valuing lost data is an approach wherein the costs of obtaining some data, if it were to be destroyed, are considered as the value. • Valuing data by considering the data lifecycle. This involves thinking about how data is created or obtained in the first place, how it is made available to people to use, and how data is retired, either through archiving or physical destruction. The costs incurred in all these stages represent the value of the data. • Classifying data: Data can be classified in various ways. The one chosen should fulfil the organisational requirements to the best possible extent. The typical classification types are: • Operational, Tactical and Strategic data • Security based classification • Organisation-wide, functional-area and service-specific data. • Setting data standards: One of the key responsibilities of data administration is to ensure that standards for data and metadata are established and followed. Standards for naming, ownership and classification should be put in place for efficient data management. • Data ownership: Data administration should also establish the responsibilities of a data owner. The responsibilities include: • Agreeing a business description and the purpose for the data • Defining who can create, amend, read and delete occurrences of the data • Authorising changes in the way data is captured or derived • Approving any format, domain and value ranges • Approving the relevant level of security, including making sure that legal requirements and internal policies about data security are adhered to. • Data migration: One significant activity in projects initiated to replace existing services with new services is ‘data migration’. It is essential to transfer good-quality data from the existing systems and services to the new ones. Hence, data migration standards, procedures and processes should be put in place by data management and where possible appropriate data migration tools should be used. • Data capture: Data management should also help with effective measures and ways for data capturing. Data management process should have standards for capturing data in various environments including non-structured data. The aim should be to capture data as quickly and accurately as possible. • Data storage: This is a very critical aspect of overall data management. Size of data to be maintained and cost of storing the data are the two important considerations while deciding data storage requirements. Understanding technology developments and identifying opportunities for the business to exploit the information resources effectively by making the best use of new technology is another key responsibility of data management. • Data retrieval and usage: Ability to retrieve information and making it available to the right people at the right time is most important outcome expected from data management. The confidentiality, integrity and availability aspects must be covered while defining the relevant standards and procedures. • Data integrity and related issues: Data integrity is concerned with ensuring that the data is of high quality and uncorrupted. It also involves version controlling and preventing duplication. The other areas to be taken care of are: • Providing controlled access to data; • Implementing policies on archival and retention of data, meeting regulatory requirements where required; • Performing periodic data integrity check; and • Recovery of lost or corrupted data. Let’s learn about application management in the next slide.

4.12 Application Management

Application Management • An application is defined as – “the software program or programs that perform those specific functions that directly support the execution of business processes and/or procedures”. Applications are a critical part of the overall service. But, from a service provision perspective, the seamless integration of applications, infrastructure, processes, tools and management is more important. • Application management to be successful, should pay due attention to two aspects. The first aspect is ‘Designing and developing applications to support development of a service’ and the second one is ‘taking a global view of services and the constituent applications’. These two approaches are more commonly known as: • Service Development Lifecycle or SDLC Approach; and • Global View Approach. • We shall discuss these two approaches in more detail now.

4.13 SDLC Approach

SDLC Approach • The Service Development Lifecycle approach, also known as SDLC approach, is a systematic approach to problem solving and is composed of the following steps: • Performing a feasibility study; • Conducting an analysis; • Designing and developing the service solution; • Testing the solution; • Implementation of the service; • Evaluation of the service after go-live; and • Maintenance of the service till retirement. Let’s look into the global view of the service in the next slide.

4.14 Global view of the service

Global view of the service The ‘Global view’ approach considers all services to ensure the on-going maintainability and manageability of the applications. The key aspects of this approach are that: • All applications are described in a consistent manner – via an Application Portfolio that is managed and maintained to enable alignment with dynamic business needs. This enables a common understanding of the application’s purpose and functionality across the organisation and customer groups. • Consistency of approach to development is enforced through a limited number of application frameworks and design patterns and through a ‘re-use’ first philosophy. This ensures minimisation of diversity in application development and deployment. It also helps in better interface and integration of applications where required. • Common software components to meet management and operational requirements are created or acquired at an ‘organisational’ level and used by individual systems as they are designed and built. This results in cost-efficiency and better resource utilisation across the organisation. Knowledge and information sharing will also become easy.

4.15 Application Management Consideration

We shall now discuss – what is an application portfolio and how it is linked to service portfolio. • An Application Portfolio is a full record of all applications within the organisation and is dynamic in its content. This is mainly used by the IT organisation and is not usually visible to the customers and users. The application management team owns this portfolio and makes extensive use in delivering the services. • Linking Application and Service Portfolios: There are various approaches to managing the application portfolio. Each organisation will have to analyse and choose the one that suits its organisational requirements. The options are: • To maintain a separate Application Portfolio with required attributes or to store it within the Configuration Management System, together with the appropriate relationships to other configuration items; or • To combine the Application Portfolio with the Service Portfolio. The advantage here is the unified management of both the portfolios leading to efficient maintenance. Whatever option an organisation adopts, it is essential to define the relationships and linkages between the applications and the services they support and the infrastructure components used. Understanding this relationship is just one single factor that can take service management to a higher level of delivering quality services.

4.16 Application Portfolio attributes

A sample list of Application Portfolio attributes is provided in this slide. Please spare a few minutes to go through the list and get a feel of what information goes into the application portfolio for each application that is used in providing IT services to business and customers. Let’s look into application management considerations in the next slide.

4.17 Application Management Considerations

Application Management Considerations • Developing or adopting ‘Application frameworks’ is an essential aspect of application management as well as service management. Application frameworks induce standardisation of activities and deliverables in various areas of application management. • An Application framework is a powerful tool and covers all management and operational aspects; and • Provides solutions for all the management and operational requirements that surround an application. Application frameworks should not be developed in isolation, but should be closely integrated with the service, infrastructure, environment and data architectures. • We shall now discuss some guidelines for developing architectures, application frameworks and standards. • Architecture-related activities should be planned and managed separately from individual system-based software projects. These activities should be performed for the benefit of more than just one application. • It is a good practice to identify the types of application and group them into families. All application in the same family should be built and managed using the same application framework. It should also be ensured that organisational and industry standards should be used in development and usage of the application architectures and frameworks. We will continue with application management considerations in the next slide.

4.18 Application Management Considerations

Application Management Consideration • After having discussed about application frameworks and architectures we shall now discuss the other aspects of application management. Let us start with the tools and repository aspect. • Computer Assisted or Aided Software Engineering, popularly known as CASE tools, can be used to perform a number of application management activities, especially in the design and development of applications. • CASE tools can be effectively used to specify requirements, draw design diagrams as per specific modelling standards, generate complete applications that are almost ready to be deployed. • These tools also include repository features for storing and managing all the elements that are created during application development. They also include version control and consistency checks features. • Design of specific applications: The design phase takes all documented and signed-off requirements into consideration and turns them into the specification that will be used to develop the application. It is important to plan and create flexible designs, so that any changes requested later in the design phase will not drift back to the initial stage of designing. The goal for designs should be to meet the organisation’s requirements. Design includes the design of the application itself, and the design of the infrastructure and environment within which the application operates and hence an overall integrated approach should be adopted for the design of services. • Managing trade-offs: This aspect focuses on balancing the relationship among resources, the project schedule, and quality of the application being developed. It is essential to ensure that management and operational requirements are also taken care of along with balancing resources, schedule and quality. • Typical design outputs: The typical outputs of application design are: • Input and output design, including forms and reports • A usable user interface design • A suitable data/object model • A process flow or workflow model • Detailed specifications for update and read-only processes • Mechanisms for achieving audit controls, security, confidentiality and privacy • A technology specific ‘physical’ design • Scripts for testing the systems design • Interfaces and dependencies on other applications. • Design patterns: A design pattern is a general, repeatable solution to a commonly occurring problem in software design. ‘Separation of Concerns’ is a modern principle which is used as a basis for design patterns. Adopting this principle helps in dividing applications into components with strong cohesion and minimal coupling. This allows modification to individual components with little or no impact on other components. • Developing individual applications: The design phase is followed by development phase. Application components are coded or acquired, integrated and tested. Application development phase must ensure that management and operational aspects as designed are addressed and that the application fits into the overall service solution. • One important good practice to be adopted during application development phase is the use of ‘consistent coding conventions’. Coding conventions result in precise, readable and unambiguous source code that is consistent with the organisational coding and management standards and is as intuitive to follow as possible. • Templates and code generation: Code generation tools may be used to create templates that help in faster application component development. Some tools also automatically generate code based on design models and coding conventions. These are very useful in developing consistent code within shorter timescales. • Embedded application instrumentation: Application development also involves incorporating instrumentation for application drivers or middleware components within the applications. A number of technologies are available and application program interfaces can be used to incorporate the instrumentation requirements in the applications. • Diagnostic hooks are used to collect and provide the information necessary to solve problems and application errors rapidly and help restore the service. These are also helpful during application testing and may be used to provide measurement and management information of applications. We will next see the major outputs from development.

4.19 Major outputs from development

Major outputs from development Apart from developing and testing the applications, the application development teams are responsible for delivering a number of other outputs. These include: • Scripts to be run before or after deployment • Scripts to start or stop the application • Scripts to check hardware and software configurations of target environments before deployment or installation • Specification of metrics and events that can be retrieved from the application and that indicate the performance status of the application • Customised scripts initiated by Service Operation staff to manage the application • Specification of access control information for the system resources used by an application • Specification of the details required to track an application’s major transactions • Service Level Agreement targets and requirements • Operational requirements and documentation • Support requirements • Application recovery and backups • Other IT Service Management requirements and targets Let’s look into what we have learnt so far in this unit.

4.20 Summary

So far we have learned about the requirements engineering categorized into functional, management and operational and usability requirements. We have also learnt about the requirements investigating techniques, the problems and how we document it. We also looked into data and information management, the two approaches of application management namely service development lifecycle or SDLC approach and global view approach. In the end we also learned about the major outputs delivered from developing and testing these applications.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Phone Number*
Job Title*