Skip to content

IDENTIFYING KPIs

Content change

The content of this page has changed from that seen in the overview video.

It has been simplified, so as to focus on the core aspects.

The process of identifying Key Performance Indicators (KPIs) is a strategic step that directly leverages the insights gained from defining Functional Requirements, Non-Functional Requirements, and conducting an Empathy Analysis. These three processes provide a comprehensive understanding of what the software should do, how well it should do it, and who it serves and how they feel about it, all of which are crucial for determining what success looks like.

Here's how each contributes to identifying KPIs:

1. How Functional Requirements (FRs) Identify KPIs

Functional Requirements define the specific actions, features, and capabilities the application must perform. When identifying KPIs from FRs, we ask: "Is this feature being used as intended, and is it achieving its core purpose for the user?"

  • Direct Translation of Core Actions: If an FR states, "The application shall allow users to input their monthly rental or mortgage payment," a related KPI could be the "Rate of successful rent/mortgage payment entries per active user." This measures if users are actually performing this core function.

  • Measuring Feature Adoption: If an FR says, "The application shall provide a forward-looking forecast of upcoming payments," a KPI might be "Percentage of active users who access the forecasting feature." This tells us if a developed feature is being adopted.

  • Assessing Desired Outcomes: For an FR like "The application shall allow users to track payments made towards their rental/mortgage," a KPI could be "On-Time Payment Rate for tracked bills." This measures if the tracking feature is helping users achieve the desired outcome of timely payments.

In essence, FRs tell us what to build, and KPIs derived from them tell us if that what is actually being used and delivering on its primary function.

2. How Non-Functional Requirements (NFRs) Identify KPIs

Non-Functional Requirements define the quality attributes of the system – how well it performs. They dictate performance, security, usability, reliability, scalability, etc. KPIs derived from NFRs are direct measurements of these quality aspects.

  • Measuring Performance Attributes: If an NFR states, "The application shall load within 3 seconds," a KPI is directly "Average Application Load Time." Similarly, for "API response time shall be within 1 second," the KPI is "Average API Response Time."

  • Assessing Reliability and Availability: An NFR like "The application shall maintain an uptime of 99.9%" directly leads to the KPI "System Uptime Percentage." Quantifying Security: If an NFR demands robust security, KPIs like "Number of Critical Security Vulnerabilities Identified" or "Number of Security Incidents/Breaches" are essential.

  • Evaluating Usability: An NFR about intuitive UI might lead to a KPI like "Task Completion Time" for key workflows or "Number of Support Tickets related to UI Confusion." (Though usability often benefits more from qualitative feedback, some quantitative measures exist).

  • Confirming Testing Rigor: The client's expectation of rigorous testing, which aligns with NFRs for quality, directly informs KPIs like "Test Coverage Percentage," "Defect Escape Rate," and "Automated Test Pass Rate."

NFRs tell us how the system should be built, and KPIs derived from them tell us if it's meeting those quality standards.

3. How Empathy Analysis (EA) Identifies KPIs

Empathy Analysis, by exploring the "Think, Say, Do, Feel" of different user types (Client, Developer, End User), provides invaluable context and motivation behind the FRs and NFRs. It helps identify the why behind the features and quality attributes, ensuring KPIs measure what truly matters to the stakeholders.

  • From End User's "Feel": If end users "feel overwhelmed" by managing bills or "anxious" about missing payments, then KPIs like "On-Time Payment Rate" or "User-Reported Stress Reduction Score" (if measurable through surveys) become critical.

  • If they "feel empowered" by understanding their spending, a KPI like "Average Savings Identified/Achieved by Users" or "Budget Adherence Rate" directly reflects this feeling of control and benefit.

  • If they "feel frustrated" by a confusing interface, KPIs like "Task Completion Success Rate" or "Support Tickets related to Usability" will highlight areas for improvement.

  • From Client's "Think/Feel": If the client "thinks" about ROI and "feels anxious" about market share, KPIs like "User Registration Rate," "Active User Rate," and "Retention Rate" are paramount, as they directly address these business concerns.

If they "feel confident" about a secure product, "Security Vulnerability Count" or "Zero Data Breach Incidents" become key.

  • From Developer's "Think/Feel": If developers "feel challenged" by complex integrations or "proud" of robust code, KPIs like "API Response Time," "Defect Density," and "Automated Test Pass Rate" validate their technical efforts and address their concerns about code quality and maintainability.

EA helps prioritize which FRs and NFRs are most critical from a human perspective, guiding the selection of the most impactful KPIs that truly reflect success in the eyes of everyone involved. It bridges the gap between technical specifications and human experience.

Conclusion: The Holistic View

By combining insights from Functional Requirements, Non-Functional Requirements, and Empathy Analysis, we ensure that the identified KPIs are:

  • Comprehensive: Covering both what the system does and how well it does it.

  • Relevant: Measuring what truly matters to the users and the business.

  • Actionable: Providing clear data points that can inform decisions and drive improvements in the software development lifecycle.

This integrated approach leads to a robust set of KPIs that accurately reflect the application's performance, quality, and its ability to meet the needs and expectations of all stakeholders.