Use Case Development
This blog serves as a guide to structure and finalise use cases for any IT Project. This page focuses on establishing a structured framework and key parameters that must be defined before moving forward with implementation of any use case.
To achieve this, we are adopting the Why / How / What framework, which ensures that each use case has a clear justification (Why), a methodological structure (How), and is outcome driven (What). Additionally, within the Why / How / What framework, we have also defined sub-parameters which were identified from software development best practices, that need to be answered to ensure clarity, and alignment with business objectives.
To demonstrate this approach, we provide an example use case which is “Two-Factor Authentication (2FA) for a Web Application”, helping readers understand how to apply these concepts in a structured manner, and build use cases for your specific projects. This example serves as a reference model, demonstrating how we can answer all the key questions of the framework and its parameters.
This blog is structured into two sections, each serving a distinct purpose:
Section I: Why / How / What Framework
Before implementing any use case, it is essential to establish its purpose, process, and expected outcome. This section introduces the Why / How / What framework, which helps structure each use case with a clear justification, execution plan, and measurable outcome.
Section II: Defining Use Case Parameters
This section goes deeper into the specific parameters that must be addressed within the Why / How / What framework to ensure clarity, and alignment with business objectives. For clarity, we used a real-world example use case which is a Two-Factor Authentication (2FA) for a Web Application as a reference model, demonstrating how these parameters can be applied to each use case.
Section I. Why / How / What Framework
As part of our Use Case Development process, we are adopting the Why / How / What framework to ensure clarity before moving forward with implementation. This approach helps us define the purpose, process, and expected outcome of each use case, ensuring that every use case we develop directly adds business value. To explain this framework, we will talk about a real-world software development use case which is ”Implementing Two-Factor Authentication (2FA) for a Web Application”. Before proceeding with any use case, it is essential to have clear answers to the following:
1. WHY? (Why are we doing this?)
This defines the business problem or need that the use case is addressing. It ensures that we are solving a real problem. e.g. in 2FA the “WHY” is to enhance security and prevent unauthorized access to user accounts. Weak passwords alone are not sufficient, and account takeovers due to compromised passwords pose a major security risk.
2. HOW? (How will we do it?)
This describes the approach and methodology that will be used to solve the problem. It includes technologies, workflows, and strategies that will be implemented. e.g. in 2FA the “HOW” is to implement an extra authentication layer by requiring users to verify their login with a one-time password (OTP) sent via SMS or an authenticator app after entering their credentials. MFA (Multi-Factor Authentication) services such as Google Authenticator, Microsoft Authenticator, and Twilio SMS API will be used.
3. WHAT? (What will be the outcome?)
This clarifies the final output / solution, helping stakeholders understand the expected benefits of the use case. e.g. in 2FA the “WHAT” is a secure authentication system that prevents unauthorized logins by requiring users to verify their identity using MFA, thereby reducing security breaches, strengthening account security, and improving user trust.
By applying this Why / How / What framework, we ensure that each use case is strategically justified, methodologically planned, and outcome-driven, making the implementation process aligned with business objectives. Before moving forward with any use case, it is mandatory to have clear answers to these three aspects.
Section II: Defining Use Case Parameters
As per software development best practices (references provided below), defining a use case is not just about answering Why, How, and What, rather it also involves detailing specific sub-parameters that ensure clarity. Without addressing these key parameters, use cases may remain ambiguous, or incomplete for implementation. To explain these parameters, we will again talk about a real-world software development use case which is ”Implementing Two-Factor Authentication (2FA) for a Web Application”.
Modern applications require strong security to prevent unauthorized access. A common pain point for many companies is that users rely on weak passwords, making accounts vulnerable to hacking. To enhance security, companies implement Two-Factor Authentication (2FA), an extra layer of protection that requires users to verify their identity not just with a password but also with a one-time code sent to their mobile device. To ensure clarity, let’s apply the key parameters to this use case to ensure that before implementing 2FA, all essential questions are answered:
1. WHY? (Why are we doing this?)
The below mentioned four parameters justify why the use case exists by focusing on business needs.
1.1 Business Problem / Pain Points: What specific issue are we solving? e.g. Users are experiencing unauthorized access due to weak authentication.
1.2 Business Value / Expected Impact: How does this improve the business? e.g. Implementing Multi-Factor Authentication (MFA) to enhance security and reduce unauthorized logins.
1.3 Key Performance Indicators (KPIs): How will success be measured? e.g. Reduce unauthorized access attempts by 95% in the first 6 months.
2. HOW? (How will we do it?)
These parameters define how the use case will work from a functional and technical perspective.
2.1 Primary Actor (Users/Systems Involved): Who interacts with this use case? e.g. The end user logging in, the authentication server, and the MFA system.
2.2 Scope & Boundaries: What is included/excluded? e.g. Only web-based logins are covered, mobile apps are not in scope.
2.3 Preconditions: What must be true before this use case starts? e.g. The user must already have an account registered in the system.
2.4 Triggers: What event initiates this use case? e.g. A user enters their credentials and clicks “Login”.
2.5 Basic Flow (Main Success Scenario): Step-by-step process leading to success. e.g.
- User enters credentials.
- System verifies username and password.
- If correct, system requests an MFA code.
- User enters the MFA code.
- Access is granted.
2.6 Alternative Flows / Exceptions: What can go wrong? How is it handled? e.g.
- Wrong Password? → Show error and allow retry.
- MFA Code Expired? → Prompt user to resend code.
- Integration Requirements → Does this connect with other systems? e.g. The authentication system integrates with MFA services (Google Authenticator, SMS).
- Data Requirements → What data is required or stored? e.g. Store login history (IP, device info) for security monitoring.
3. WHAT? (What will be the outcome?)
The below mentioned four parameters define the final result of the use case.
3.1 Postconditions: What will the system look like after execution? e.g. If authentication is successful, the user is logged in and redirected to their dashboard.
3.2 Expected Outcome: What should this use case achieve? e.g. Users can log in securely using MFA, reducing security risks.
3.3 Dashboards / Reporting Needs: What analytics or reports are needed? e.g. A dashboard showing failed login attempts, successful MFA verifications, and system alerts.
3.4 Alerts & Notifications: Who gets notified and when? e.g. If a user fails multiple login attempts, they receive an email warning them of suspicious activity.
Conclusion
This blog provides a structured approach to defining use cases. By using the Why / How / What framework, along with clearly defined sub-parameters, we establish a methodological process to ensure that each use case is well structured, and aligned with business objectives. This document serves as a guideline and reference for how to structure and finalize each use case before moving forward with implementation.
The parameters and framework outlined in this document are based on software development best practices, but they are not the only way to formulate a use case. There may be alternative approaches, or some parameters may need adjustments based on project requirements. If anyone has suggestions for improving this framework whether by adding, modifying, or removing parameters, constructive feedback is always welcome. Additionally, the example use case of Two-Factor Authentication (2FA) for a Web Application serves as a reference model for how we should approach the use case development in IT projects.
This structure ensures that all necessary questions are addressed, providing clarity and confidence before implementation begins. If you have any comments, suggestions, or alternative viewpoints, feel free to add your comments on this blog.