Some Important Use Cases

Use cases can be very helpful. Documented use cases can help us understand the requirements of users from a real-world perspective. This can help us define and refine accurate business processes and requirements.

For functional requirements, we’re trying to identify the business requirements using business process mapping, how people work at the moment. So we can create functional requirements from those business requirements. We can also look to, with our stakeholders, agree a change to those processes to reengineer those processes. So BPM is mapping the existing processes. BPR is where we see whether we can improve on those processes, whether we can introduce efficiencies. If we’re changing, for example, the method of authentication, we’re implementing single sign-on with multifactor authentication, that will change the way people work, and we may need to alter and amend the target processes accordingly. So can we improve the existing processes with updated technologies?

We need to understand the current requirements and also the future capabilities that will arise from our new identity and access management system. We also need to consider federation and integration. Typically, identity and access management technologies offer significant capabilities in these areas. They can enable us to do things differently. They can offer us increased resilience. They can offer us increased levels of access. So we may want to explore with our stakeholders internally and externally, business-to-business, business-to-customer, alongside our internal stakeholders, what they may want from our identity and access management system. Business-to-business, it makes it better, just-in-time supply chain logistics. For our customers, it may better enable single sign-on.

If we have multiple services, they only need to manage a single set of credentials as a customer to sign on to all of our services.

We also want to establish a set of requirements around availability.

This is a fairly broad set of requirements, including the responsiveness of any service. So how quickly will the log-on process be performed? Will federation take place? How quickly will the account be provisioned through enrollment? So these service responsiveness standards are important. And linked to that are the availability standards. So if we know it takes 24 hours to provision a new account, that’s the service responsiveness. The service availability is the uptime related to these services. We need to understand them because during the design stage, we are looking to implement something, and it’s easier to make changes to meet the requirements around availability standards at the design stage than at the implementation stage. It’s much easier to deal with this upfront.

Ultimately, this can lead to Service-Level Agreements or Organization-Level Agreements, SLAs or OLAs, with our vendors, with our customers, or internally between different sections of our business. And we see some very formal service-level agreements within group company structures, where you have multiple businesses within an umbrella group, where group providers of services like IT or security services have very stringent service-level agreements. The success criteria, how do we know if we’re successful? Our criteria need to be objective. Typically, we refer to the acronym SMART when we talk about objective criteria that need to be measurable.

So we have SMART, which is something that is specific, a target that is Specific, that is Measurable, that is Agreed, and agreed by the stakeholder and also by the service provider. There’s no point in having an objective metric that is proposed by the stakeholder, but which is not agreed by the upstream service provided, by the cloud service provider, for instance. It needs to be Realistic, and again, we need to make sure that any success criteria can be delivered. It’s very easy to fall into the trap of overpromising and under-delivery. They also need to be Time bound– when are we doing this? At what point will this be delivered.