ITIL for BAs. Part VI; “Non-functional Requirements”

The two most recent posts about ITIL for BAs emphasized the roles of the IT Service, the Service Catalog, Service Level Management, and the Service Owner in encapsulating IT as a Service Provider.

It would be natural at this point to explore the ITIL/BA relationship from the Service life cycle point of view.  Much of both Service Strategy and Service Design address what are typically referred to as non-functional or supplemental requirements.  ITIL refers to them as Quality of Service (QoS) requirements.

Other BAs have rightfully pointed out (here is a good example) that QoS requirements frequently do not get the attention they deserve.  There are a number of contributing factors:

• Stakeholders in QoS requirements are generally not the same as the functional requirements stakeholders
• The negotiations involved in QoS requirements and functional requirements are different:
  • Functional requirements are normally negotiated by reconciling scope, schedule, and cost factors with development/test/release resources.
  • QoS requirements need to be negotiated by reconciling quality characteristics (availability, capacity, continuity, etc.) with IT infrastructure capabilities (assets), constraints (architecture), and even policy (especially in the area of information security management)
• Elicitation techniques such as brainstorming, focus groups, interface identification, prototyping, requirements workshops, and reverse engineering are primarily used for functional requirements elicitation.
• QoS requirements traceability is evasive; it’s one matter to trace the relationship between a function point in a software library to a step in a business process; it’s quite another matter to trace, say, the specific capacity characteristics of a particular IT component to the variety of business demands relying on that capacity.

It is also interesting to note that the BABOK addresses non-functional requirements most fully in Requirements Analysis rather than in Elicitation. 

ITIL’s coverage of QoS requirements is explicit, robust, and effective at contributing to deep business/IT integration.  This is evident particularly in the processes defined (Demand Management, Capacity Management, etc.), the extent to which those processes are embedded in the early stages of the IT Service life cycle, and the way in which ITIL defines “utility” (what the IT Service can do) and “warranty” (how well it does it) and then relates utility and warranty directly to their role in business strategy.  In my next post, we’ll cover that in more detail and then move into specific QoS-related processes and roles.

If you have any good stories to share about your BA experiences and the challenges around QoS requirements, please share them – your comments are great food for thought for your fellow BAs.

Meanwhile, Happy New Year to you and yours!