Chapter 16
Technology-Related Activities
THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
- ✓ The service design activities and techniques within requirements engineering
- ✓ The service design activities and techniques within data and information management
- ✓ The service design activities and techniques associated with application management
This chapter covers the management of technology-related activities commonly performed in the service design stage. It covers requirements engineering in relation to the activities/techniques associated with data and information management as well as application management. To meet the learning outcomes and examination level of difficulty, you must ensure that you are able to understand, describe, identify, demonstrate, apply, distinguish, produce, decide, and analyze the service design activities and techniques within requirements engineering, within data and information management, and associated with application management.
Service Design Activities and Techniques within Requirements Engineering
Requirements engineering is the name given to the approach by which we ascertain, understand, and document the requirements of the business, users, and other stakeholders. This enables service design to understand what is required and ensures the traceability of changes to each requirement.
This process is made up of three stages. The first is elicitation, when we try and get the business to describe its requirements. The second stage is analysis, when we seek to understand those requirements. This stage may feed back into the elicitation stage as we seek further clarification. The final stage is validation. The aim of these three stages is to be able to produce a rigorous, complete requirements document.
The core of this document is a repository of individual requirements. Some of these requirements are technical and originate from IT to ensure that the new service fits the current architecture. All requirements need to be agreed with the business. This chapter focuses on the requirements for the technology related to a service. There are many other areas where requirements will need to be defined, but we are not considering them here. They could include user and support staff training, marketing and communication related to the service and its deployment, documentation requirements, and organizational and cultural readiness. It is the responsibility of design coordination to set the standards and methods for defining requirements and ensure that they are followed during the service design stage. The design coordination process was covered in Chapter 12, “Service Design Processes: Design Coordination and Service Catalog Management.”
Types of Requirement
By analyzing current and required business processes, we can ascertain the functional requirements that are to be met through IT services (comprising applications, data, infrastructure, environment, and support skills). There are commonly said to be three major types of requirements for any system. These are functional, management and operational, and usability requirements. Let’s examine the ITIL definitions for them:
- Functional requirements. ITIL defines these as the requirements that directly support a particular business function or business process or remove a customer or user constraint. These requirements describe the utility aspects of a service.
- Management and operational requirements. These are sometimes referred to as nonfunctional requirements. ITIL defines these as the requirements that address the need for an available and secure service and deal with such issues as operability, management needs, and security. These requirements describe the warranty aspects of a service.
- Usability requirements. ITIL says these requirements are concerned with how easy the service is to use and how easily a user may achieve their desired outcomes. They include the “look and feel” requirements and so can influence user perceptions of a service.
Functional Requirements
Functional requirements describe the things a service is intended to do—in other words, the utility it will provide. There are a number of different methods for documenting these requirements:
- A description of tasks or functions that the service must perform.
- A system context diagram that shows all information exchanges between the IT service and the sources or destinations of data used by the service.
- A use case model that shows the boundary of the system, the interaction with other services, and the scenarios that need to be supported. These scenarios can be expanded later into test cases.
- A data flow or object diagram that describes the different “objects” in the service, their mutual relationships, and their internal structure and shows how the inputs will be transformed into the outputs. Sometimes textual descriptions are used.
Management and Operational Requirements
Management and operational requirements (or nonfunctional requirements) define requirements and constraints. They are useful for sizing the service and estimating cost and so can help when assessing whether the proposed IT service is viable. They are useful in reminding developers to think beyond the purely functional requirements.
These requirements ensure that we consider how the service will perform. Requirements in the following areas need to be clarified:
- Manageability
- Efficiency
- Availability and reliability
- Capacity and performance
- Security
- Installation, automated or otherwise
- Service continuity, including the required levels of resilience and recovery targets
- Monitoring and management requirements
- Maintainability requirements covering how easily the application can be adjusted, corrected, maintained, and changed for future requirements
- Operability requirements to ensure that the application does not impact other applications
- Measurability and reportability requirements defining the measurements and reporting needed
As you know, ITIL says that a service only delivers value when both utility and warranty aspects are delivered to the level required by the business. The functional requirements define the utility, and the management and operational requirements ensure that the warranty of the application or service is sufficient. These aspects must be tested during transition to ensure that the live service will deliver value. At this stage, they can be used to design test plans for testing the applications.
Usability Requirements
These requirements define what users expect in terms of how easy it will be to use the service. This requires setting specific standards against which the service can be evaluated.
In order to establish usability requirements, care must be taken to establish the types of users likely to use the service and to understand their varied needs. For example, users who are color-blind would not find a service that relied heavily on color differentiation easy to use, or users working in a second language may have difficulty with screen terminology that does not translate well. Similarly, the creator of a website used by the public should recognize and take into consideration the literacy level of the general population.
Requirements Investigation Techniques
The following techniques can be used for requirements gathering:
- Interviews
- Workshops
- Observation
- Protocol analysis
- Shadowing
- Scenario analysis
- Prototyping
- Questionnaires
- Activity sampling
Interviews
The interview is a key tool used to gather requirements. It also helps to build a relationship with key stakeholders and facilitates the gathering of information about the business situation, including issues and problems.
There are three areas that are considered during interviews:
- Any requirements for current business processes that the new business system needs to address
- Current problems to be tackled
- New features required
The interviewing process will be most productive if it is thoroughly planned. This helps avoid unnecessary explanations. The classic questions of why, what, who, when, where, and how provide an excellent framework. Formally closing the interview by summarizing the points made and the actions agreed on is also important. Interviewing helps build a relationship with the users, and is an opportunity to gather information from all the stakeholders and may open up new areas for investigation.
Interviews can be time-consuming, and because they are carried out individually, they don’t offer any opportunity for resolving disagreements between users and building a consensus.
Workshops
Another requirements-gathering technique is running workshops. They provide a forum for discussion, where requirements can be captured, conflicts resolved, and a consensus reached.
Facilitating workshops can be challenging; it is important to have the correct people attend and then to ensure that different views are heard. It is essential that no one view is allowed to dominate and that, wherever possible, progress is made toward a common view. Figure 16.1 shows some techniques that may be useful for conducting a workshop. The key points of discussion should be recorded, and they should be summarized at the end of the workshop. Any agreed actions should be assigned to an owner.
Figure 16.1 Requirements workshop techniques
Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.
Observation
Observing people at work performing a specific task provides useful information about the business and its work practices. This enables a more complete understanding of business problems and difficulties, which helps when designing solutions because the solutions need to be acceptable to the business.
Conversely, being observed can be rather unnerving, and the old saying “you change when being observed” needs to be factored into your approach and findings.
Protocol Analysis
Protocol analysis is simply getting the users to perform a task and describe each step as they perform it. Users are encouraged to think aloud as they solve a problem or complete a task, and their description of what they are doing and why can then be analyzed.
Shadowing
Shadowing involves understanding how someone works by following them for a period of time, such as one day. This can be extremely helpful in understanding someone’s role because the actual activities they carry out may not mirror their job description. Questions can be asked at the time, when the work is being carried out, to validate any assumptions.
Scenario Analysis
Scenario analysis traces a transaction from an initial business trigger through each of the steps needed to achieve a successful outcome. In doing so, alternative approaches may be discovered. This method can be time-consuming. It may be helpful to use graphical methods of documenting the scenario, such as storyboards and decision tree diagrams.
Prototyping
Prototyping is a technique for eliciting, analyzing, demonstrating, and validating requirements. Users may find it hard to envisage what the service will look like and how they might use it. Prototyping shows how a new service will work before it has actually been built. Users can understand how they would use the service, and this may result in additional requirements. So, for example, by seeing a prototype of a stock-control service, users may realize which information they would typically need to have shown on the screen to be able to answer typical queries, without having to switch between screens.
Questionnaires
Questionnaires are used to gather limited information from large numbers of people. This can be a cost-effective way to gather information. It has the advantage that every respondent answers exactly the same questions, but this can also be limiting if the questions do not cover particular areas.
Activity Sampling
Activity sampling can be used to understand how people spend their time. For example, it can be used to see how much time is spent on processing orders, or on invoicing or sorting out queries.
Problems with Requirements Engineering
Gathering requirements accurately is critical and should not be rushed, even if timescales and budgets are tight. Pressure on developers to deliver a service may mean that they start to design the solution before the requirements have been fully understood and defined; there is a risk that the business may not receive the service it wants. Research into IT project failures shows that over 80 percent of errors are introduced at the requirements phase. This is far more than design or development errors. Most project time is taken up with the development and testing phases, but with incomplete or inaccurate requirements, this time may be spent developing a service that will prove unsatisfactory. Such fundamental errors are expensive to fix.
Requirements must be unambiguously described with clear criteria for assessing whether they have been delivered. It is essential to include the nontechnical requirements and to resist requirements creep—the gradual addition of seemingly small requirements that together will have a significant impact on the cost and effort required from the project.
The following list includes some other problems that may be encountered when requirements are gathered:
- Lack of relevance to the objectives of the service
- Lack of clarity or ambiguity in the wording
- Duplication between requirements
- Conflicting requirements
- Requirements without clear delivery criteria
- Users’ lack of certainty about what they need
- Inconsistent levels of detail
- Failure to include requirements from stakeholders such as service operations and support staff
Documenting Requirements
Requirements should be documented in two distinct phases: building the requirements list and, later, developing an organized requirements catalog.
- The requirements list is an informal document that includes the requirements, their source, comments, and level of detail. Each requirement in the list must be checked to see whether or not it is well formed and SMART (specific, measurable, achievable, relevant, and time-bound).
- The requirements catalog lists requirements, with each individual requirement documented using a standard template. Requirements are included only after careful scrutiny to ensure that they are complete and clearly expressed. When completed, the retirements catalog should be signed off on by the business as a true statement of the requirements.
Management of Data and Information
Data is a critical asset type; it must be managed in order to develop, deliver, and support IT services effectively. Key factors for successful data management are as follows:
- Ensuring that all users can access the information they need to do their jobs
- Ensuring that the data is exploited as much as possible by sharing it with others while storing and protecting it from unauthorized access
- Maintaining data quality so that the information used by the business is accurate, reliable, and consistent
- Fulfilling legal requirements regarding privacy, security, confidentiality, and integrity of data
- Handling data effectively and efficiently
- Using an enterprise data model to define the most important entities and their relationships, thus reducing redundancies and ensuring that the data architecture remains effective despite changes over the years
If data is not managed effectively, resources will be wasted collecting and maintaining unnecessary data, or the data that is useful may not be available to those who need it. The quality of data may be improved by using a data management process that establishes policies and standards, provides expertise, and makes it easier to handle the data aspects of new services.
There are four areas of management included within the scope of data/information management.
Management of Data Resources Management of data resources involves ensuring that all the data resources are known and assigning ownership of data and metadata. This includes responsibility for the following activities:
- Defining information needs
- Constructing a data inventory and an enterprise data model
- Identifying data duplication and deficiencies
- Maintaining a catalog/index of data/information content
- Measuring the cost and value of the organization’s data
Management of Data/Information Technology Management of data/information technology includes the management of the IT that underpins the organization’s information systems. This includes processes such as database design and database administration, carried out by specialist staff.
Management of Information Processes Management of information processes includes the activities of creating, collecting, accessing, modifying, storing, deleting, and archiving data—that is, the data lifecycle.
Management of Data Standards and Policies Management of data standards and policies includes the following activities:
- Defining policies for procedures
- Defining responsibilities for data management in the organization
- Defining technical policies, architectures, and standards that will apply to the IT infrastructure supporting the organization’s information systems
Data Management and the Service Lifecycle
A lifecycle will help in understanding the use of data in business processes. We need to know who will access the data and how and why this will be done. We need to maintain data quality and plan for its eventual disposal
Classifying Data
Data can be initially classified as operational, tactical, or strategic:
- Operational data is necessary for an organization to function and can be regarded as the lowest, most specific level.
- Tactical data is usually needed by second-line management—or higher—and is typically concerned with summarized data and historical data, typically year-to-year data or quarterly data.
- Strategic data is often concerned with longer-term trends and comparison with the outside world. This involves bringing together the operational and tactical data from many different areas with relevant external data.
Data management requires setting standards for naming conventions, metadata, ownership, and format and the use of appropriate tools for data migration and capture.
Management of Applications
Now we’ll consider service design activities and techniques associated with application management. Let’s start with a definition for the term application.
An application is software that provides functions that are required by an IT service. An application can be part of more than one IT service. An application runs on one or more servers or clients.
Applications are one component of a service, along with the hardware, operating system, and so on. They must meet both the functional and nonfunctional requirements in order to work successfully.
Two alternative approaches are necessary to fully implement management of applications:
- Using the extended service development lifecycle (SDLC) is a systematic approach to problem solving, comprising a feasibility study, analysis, design, testing, implementation, evaluation, and maintenance.
- The other approach takes a global view of all services to ensure the ongoing maintainability and manageability of the applications:
- Applications are described in an application portfolio maintained to enable alignment with changing business needs.
- Consistency in development is enforced through using a limited number of application frameworks and adopting a “reuse first” philosophy.
- Common software components are created or acquired at an organizational level and used by individual systems to support the development of a service.
The Application Portfolio
The portfolio provides a full record of all applications within the organization. The data for each application will include a number of attributes for each service. (As a reminder, an attribute is a piece of information about a CI or service.) Figure 16.2 shows examples of the attributes that may be recorded for specific applications.
Figure 16.2 Application portfolio attributes example
Copyright © AXELOS Limited 2010. All rights reserved. Material is reproduced under license from AXELOS.
Linking Application and Service Portfolio
Some organizations choose to have a separate application portfolio with separate attributes, while others store the application portfolio within the configuration management system (CMS) together with the appropriate relationships. Other organizations combine the application portfolio with the service portfolio. There is no one correct approach; it is for each organization to decide the most appropriate strategy for its own needs.
Application Frameworks
An application framework can cover all management and operational aspects, providing solutions for all of an application’s management and operational requirements. Implied in the use of application frameworks is the concept of standardization. The service, infrastructure, environment, and data architectures must all be closely integrated with the application architecture and framework. This means a separation between designing applications and designing application frameworks. Application developers should focus on a single application, while application framework developers should focus on more than one application and on the common features of those applications.
The Need for CASE Tools and Repositories
Specialist tools are available that support requirements-gathering processes. These are called computer-aided software engineering (CASE) tools. Application design may use CASE tools to specify requirements, draw design diagrams, or even generate complete applications or nearly complete application skeletons. These tools also provide a central location, generally called a repository, for storing and managing all the elements that are created during application development.
It is not always possible to foresee every aspect of a solution’s design ahead of time. The key is to create a flexible design so that making a change does not send developers all the way back to the beginning of the design phase. Using application frameworks, design guidelines, and checklists will help avoid this. It is important to include the management and operational requirements within the service design package and service acceptance criteria as well as the functional requirements. Trade-offs may be required between resources, the project schedule, and features required for quality.
Outputs
Here you can see a list of examples of typical outputs from an application design:
- Input, output, and user interface designs
- A suitable data/object model and 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
- Test scripts
- Interfaces and dependencies on other applications
Design Patterns
A design pattern is a general, repeatable solution to a commonly occurring problem in software design. Design patterns describe both a problem and a solution for common issues encountered during application development.
An important design principle used as the basis for a large number of design patterns is that of separation of concerns (SoC). Separation of concerns will lead to applications divided into components. The advantage of such an application is that modification can be made to individual components with little or no impact on other components.
Developing Individual Applications
Once the design phase is completed, the application development team will take the designs that have been produced and move on to developing the application. Both the application and the related environment are made ready for deployment. Application components are coded or acquired and then integrated and tested.
To ensure that the application is developed with management at the core, the development team needs to focus on ensuring that the developing phase continues to correctly address the management and operational aspects of the design (e.g., responsiveness, availability, security). All service requirements should be found in the SDP.
Templates and Code Generation
Development tools may provide a variety of templates for creating common application components. Other development tools will generate large pieces of code (skeletons) based on the design models and coding conventions. Developers can then customize the templates to suit, rather than having to design the component from scratch. The more that standard components are designed into the solution, the faster applications can be developed. Although the cost of the development of the templates needs to be considered, reusing them in this way will lead to lower costs in the long term.
Diagnostic Hooks
Diagnostic hooks are of greatest value during testing and when an error has been discovered in the production service. They mainly provide the information necessary to solve problems and application errors rapidly and restore service. They can also be used to provide measurement and management information of applications. There are four main categories:
- System-level information provided by the operating systems and hardware
- Software-level information provided by the application infrastructure components such as databases, web servers, and messaging systems
- Custom information provided by the applications
- Information on component and service performance
Outputs
The major outputs from the development phase are as follows:
- Scripts to check hardware and software configurations of target environments before deployment or installation
- Scripts to start or stop applications
- Specification of metrics and events that indicate the performance status of an application
- Customized scripts used by service operation staff to manage an application
- Access control information for the system resources used by an application
- Specification of the details required to track an application’s major transactions
- SLA targets and requirements
- Operational requirements and documentation
- Support requirements
- Application recovery and backups
Summary
This brings us to the end of the chapter. In this chapter we reviewed the management of technology-related activities commonly performed in the service design stage. We considered requirements engineering in relation to the activities/techniques associated with data and information management as well as application management.
Exam Essentials
Understand the difference between types of requirements. This includes understanding why it is important to gather information regarding each type of requirement
Be able to list the different requirements-gathering techniques. Understand when each approach should be used and the advantages and disadvantages of the different approaches.
Understand the two phases involved when documenting requirements. The two phases are building the requirements list and developing an organized requirements catalog. Understand the difference between the requirements list and the requirements catalog.
Understand the importance of data management. Be able to list and explain the four areas of management within the scope of data management.
Understand the contents and use of the applications portfolio. Be able to list typical attributes contained within the applications portfolio.
You can find the answers to the review questions in the appendix. Which of the following is NOT one of the three stages of requirements engineering? Requirements can be categorized into three types. What are they? Which of the following are valid methods of gathering requirements? Which of the following are benefits of data management? Match the category of data with its definition. Which of the following is NOT one of the four areas of management included within the scope of data/information management? There are four types of information provided by diagnostic hooks. which of the following is NOT one of them? Specialist tools are available that support requirements processes. These are called CASE tools. What does CASE stand for? What is described by using one of the following methods: a system context diagram, a use case model, or a data flow or object diagram? Which of the following statements about requirements gathering is TRUE?Review Questions