Service Design technology-related activities

Reference: ITIL v3: Service Design, chapter 5

Requirements Engineering

Requirements are defined together with the business. Business comes up with an idea. Initial estimates should be done and then the initiative is either approved or not. Once approved, it comes to IT for analysis & design. BAs and designers should perform these activities.

Requirement Types

Functional requirements

Functional requirements are expressed in the form of User Stories. These are scenarios that are easily translated into test cases.

This identifies processes, artifacts, roles, the domain model, state charts, flowcharts, interaction diagrams.

Functional requirements can be expressed as User Stories.

Management and operational requirements

Non-functional requirements. Categories:

Manageability
Efficiency
Availability and reliability
Capacity and performance
Security
Installation
Continuity
Controllability
Maintainability
Operability
Measurability and reportability

Usability requirements

Represents ease of use.

Establish performance standards for usability evaluations
Define test scenarios for usability test plans and usability testing.

Documenting requirements

Documenting requirements is best done in two distinct phases - building the requirements list and developing an organized requirements catalogue.

Each requirement in the list is checked to see whether it is well formed and SMART (Specific, Measurable, Achievable, Realistic, and Timely).

Checklist for assessing the individual and totality of 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?

Potential outcomes from the exercise:

Accept the requirement as it stands
Re-word the requirement to remove jargon and ambiguity
Merge duplicated/overlapping requirements
Take unclear and ambiguous requirements back to the users for clarification

Remarks

Flow:

Idea, Initial estimation & approval -> Analysis & Design -> Implementation -> Transition