ITIL for BAs - Part VII; What Makes a Service Valuable?

So much of a BA's life revolves around functional requirements that the non-functional aka supplemental aka Quality of Service (QoS) requirements do not receive the necessary attention.

ITIL V3 defines the value of an IT Service as consisting of:

Utility - the degree to which the service's attributes have a positive effect on the execution of the customers' tasks (e.g., steps in a business process), either by providing needed performance (functionality) or removing constraints; and

Warranty - the robustness of the service with respect to availability, capacity, security, and continuity (that is, availability as a result of a catastrophic incident)

The diagram below depicts the relationships between warranty, utility, and their respective elements:

How useful is a service that is very fit for purpose but not fit for use? The answer is that the service may have limited usefulness if its overall availability, security and responsiveness characteristics are either unpredictable or predictably very inconsistent. What about a service that is highly available, secure and responsive, but does not offer the necessary functionality? It is easier to see in this case the limited value, for the stakeholders' primary interest is the solution's functionality.

This model of a service's value suggests:

Elicitation must address both sides of the "fit for use" questions - for example:

Not only "how available must the service be", but also "what is the cost to the business when it is unavailable" and "what is the cost if we cannot recover the service quickly enough as the result of a catastrophic failure"

Not only how secure, but what are the costs and risks to the business without that level of security

Not only "what is the expected demand" but "what if the solution's response time degrades with the specified demand parameters"

Full understanding of warranty requirements can only be gained relative to the stakeholders' desired outcomes (this is in fact implied by the question "what are the costs/risks if the solution fails").

Fit-for-use requirements are met through some combination of (a) the architecture that will accommodate the solution and (b) various design elements of the solution that are necessary to make up for deficiencies in the architecture relative to those fit-for-use requirements.

Early identification of fit-for-use requirements can help the solution team leverage as much as possible from the existing architecture and then include in the design only what is necessary to close any gap.

It is vitally important to capture the "costs and risks if it fails" for use by Service Owners and the IT support team once the solution is in operation, as that information is the basis for IT's prioritization of pending Incidents.

As I noted in the previous post, the BABOK first takes on QoS requirements explicitly in the Requirements Analysis coverage (Chapter 6). Hopefully you will interpret the above to mean that there is a lot of value in addressing those requirements (a) much earlier in the elicitation activities and (b) with the involvement of a core leadership team including the IT architect and lead software engineer (among others).