Exploring the Intricate Dance Between Software Requirements and Testing Strategies.

We have reached the fifth episode of our journey into the world of software testing.

In previous articles we saw that test plan design starts from the system requirements. So this article will focus on understanding the concept of requirement and its way of representing it. We will also see how to derive a test case from system use cases.

Let's start with the definition of "requirement" (IEEE definition): "functional requirements define the behavior of the system, that is, the process or transformation that software and hardware components of the system perform on inputs to produce outputs", or just the requirements are a specification of what should be implemented. They are descriptions of how the system should behave (1.), (2.).

Instead non-functional requirements are different. In fact non-functional requirements, sometimes referred to as "quality attributes" (e.g., reliability, scalability, maintainability), focus on characteristics that describe the overall qualities or attributes of a system, rather than its specific functionalities. These requirements are often related to system performance, usability, security, and other aspects that contribute to the overall effectiveness and quality of the system.

While non-functional requirements are usually expressed in textual form and sometimes also in quantitative form with numbers or qualifiers, functional requirements can have a form that is a way to represent them.

The form of the functional requirement is closely linked to the evolution of software development processes.

When I started working in software development in 1988 the dominant development process was the Waterfall Model (3.).

The Waterfall Model introduced a linear and sequential approach to software development. In this process, requirements were predominantly represented in a comprehensive Software Requirements Specification (SRS). The Waterfall Model reflected a structured and document-centric approach to requirements, suitable for stable environments.

Later however, after 1990, Incremental and Iterative Models as RUP (3.) gradually became dominant. The Rational Unified Process (RUP) emphasized iterative development. Requirements were expressed using Use Cases, capturing interactions between users and the system in detail. This allowed for evolving requirements through iterations. The Rational Unified Process introduced a more flexible and iterative approach, emphasizing the importance of understanding user interactions through Use Cases.

Finally after 2010 the agile model became dominant. The Agile Manifesto (4.) marked a shift towards adaptive and customer-centric development. The rise of Agile Processes marked a significant shift towards adaptability and collaboration, with User Stories becoming a prevalent way to express requirements.

So we can say that throughout this evolution, the focus has shifted from rigid documentation to more dynamic and collaborative ways of representing requirements, aligning with the changing dynamics of software development.

I would like to focus this article on a real-world example of software development : "health and fitness app for personal devices".

This example aims to explore and compare the efficacy of User Stories, Use Cases and Software Requirements Document, in the context of specifying requirements for a health and fitness application designed for personal devices. The objective is to identify strengths, weaknesses, and suitability of each technique in capturing the intricate details and functionalities associated with a health-oriented mobile application.

So let's start with the most recent form of requirements: User Stories (4.).

User Stories are concise, user-focused narratives that describe a specific functionality from an end user's perspective. They emphasize collaboration and conversation and are often written in a simple, non-technical language. For our example, User Stories may include scenarios like "As a user, I want to track my daily steps to monitor my physical activity."

Here is my attempt to express the requirements for a Health and Fitness Application with user stories:

1. User Registration:
As a new user, I want to create an account easily, providing essential information such as my name, email, and password, to access personalized health features.

2. Profile Management:
As a user, I want to be able to customize my profile by adding details like age, weight, and fitness goals, enabling the app to tailor recommendations based on my individual needs.

3. Activity Tracking:
As a fitness enthusiast, I want to track my daily activities, including walked steps, covered distance, and burned calories, to monitor my overall physical activity level.

4. Workout Planning:
As a user, I want the app to suggest personalized workout plans based on my fitness goals and preferences, ensuring a personalized exercise routine.

5. Nutritional Guidance:
As a health-conscious individual, I want access to nutritional information and personalized meal plans, helping me make informed dietary choices aligned with my fitness objectives.

6. Real-time Monitoring:
As an active user, I want real-time monitoring of my heart rate, providing suggestions into the intensity of my workouts and helping me maintain a safe exercise pace.

7. Social Integration:
As a social user, I want the ability to connect with friends, share my achievements, and participate in friendly challenges, promoting a fitness community.

8. Health Reminders:
As a user, I want to receive reminders for hydration, meal timings, and workout sessions, promoting consistency in maintaining a healthy lifestyle.

9. In-App Challenges:
As a motivated user, I want to participate in challenges and competitions within the app, providing an extra incentive to achieve my fitness goals.

10. Integration with Wearables:
As a user with wearable devices, I want seamless integration with my fitness tracker or smartwatch, ensuring accurate data synchronization and a unified health tracking experience.

11. Performance Analytics:
As a fitness enthusiast, I want detailed analytics on my performance over time, including trends, achievements, and areas for improvement, aiding in continuous self-assessment.

12. Emergency Support:
As a safety-conscious user, I want quick access to emergency support features, such as an SOS button, ensuring a sense of security during outdoor activities.        

These user stories provide a foundation for developing a health and fitness application that meets to the different needs of users, focusing on personalized experiences and wellness lifestyle.

I believe that the positive aspects of representing requirements through user stories are the following:

• User-Centric Approach: Focuses on end-users and their needs, promoting a user-centric development process.
• Agile Compatibility: Ideal for Agile methodologies, allowing for flexibility and iterative development.
• Easy Comprehension: Written in plain language, making it easy for both technical and non-technical stakeholders to understand.

On the other hand, I consider the Lack of Detail a very important limitations of this technique, in fact the lack of in-depth details can lead to assumptions and misunderstandings.

After speaking about the user stories, let's move on to analyze the oldest form of requirements representation: Document of Software Requirements.

A Software Requirements Document (SRD) is a comprehensive document that outlines the functionalities, constraints, and specifications of a software application. It includes both functional and non-functional requirements, providing a detailed guide for developers, testers, and other stakeholders.

The SRD serves as a contract between the development team and stakeholders.

Here is my attempt to express the requirements for a Health and Fitness Application with Requirements Specification Document:

1. Introduction:
The Health and Fitness Application aims to provide users with a comprehensive platform to monitor, manage, and improve their overall health and fitness. This document outlines the functional and non-functional requirements necessary for the successful development and deployment of the application.


2. User Registration:
2.1 Requirement:
New users must be able to create an account by providing essential     information.
2.2 Features:
User registration form with fields for personal details.
Secure password creation.
Email verification for account activation.


3. Activity Tracking:
3.1 Requirement:
The application should track and display real-time data on users' daily activities, including steps, distance, and calories burned.
3.2 Features:
Integration with device sensors for accurate activity monitoring.
Real-time updates on the user interface.
Historical data storage and trend analysis.

 
4. Workout Planning:
4.1 Requirement:
Provide users with personalized workout plans based on their fitness goals.
4.2 Features:
Goal-setting functionality.
Intelligent algorithm for suggesting tailored workout routines.
Progress tracking and adaptive plan adjustments.
 

5. Nutritional Guidance:
5.1 Requirement:
The application should offer nutritional information and generate personalized meal plans.
5.2 Features:
Dietary preference input.
Meal recommendations based on nutritional needs.
Food log to track consumed meals.


6. Social Integration:
6.1 Requirement:
Users should be able to connect with friends, share achievements, and participate in challenges.
6.2 Features:
Friend connection functionality.
Achievement sharing on a social feed.
In-app challenges and leader-boards.


7. Real-time Monitoring:
7.1 Requirement:
Monitor users' heart rate in real-time during workouts.
7.2 Features:
Integration with heart rate monitoring devices.
Real-time display on the application interface.
Alerts for abnormal heart rates.


8. In-App Challenges:
8.1 Requirement:
Allow users to join and participate in in-app challenges.
8.2 Features:
List of available challenges.
User participation and progress tracking.
Challenge completion notifications.
 

9. Performance Analytics:
9.1 Requirement:
Provide detailed analytics on users' fitness performance.
9.2 Features:
Analytics section with performance trends.
Personalized insights and recommendations.
Gamification elements for user engagement.
 

10. Emergency Support:
10.1 Requirement:
Facilitate quick access to emergency support features.
10.2 Features:
Emergency button activation.
Alert system to notify predefined contacts.
GPS location sharing during emergencies.
 

11. Non-Functional Requirements:
11.1 Performance: The application must respond to user interactions within two seconds.
It should handle a minimum of 10,000 concurrent users.
11.2 Security:
User data must be encrypted during transmission and storage.
Robust authentication mechanisms to prevent unauthorized access.
11.3 Compatibility:
The application should be compatible with iOS and Android devices.
Support the latest versions of major browsers.        

How can we see this Requirements Specification Document is a detailed overview of the Health and Fitness Application's features, functionalities, and the criteria it must meet to ensure a successful and user-friendly experience. It serves as a foundation for development, testing, and future enhancements.

The good thing about SRD is that it provides a complete overview of the entire system and acts like a formal contract, reducing misunderstandings. The downside is that it can be time consuming and difficult to maintain as the project evolves.

Let's now look at the topic of Use Cases, the way I prefer to express requirements. The Use Cases (1.),(3.) are detailed descriptions of how a system interacts with an external entity (usually an actor, which can be a user or another system) to accomplish a specific goal. They provide a step-by-step narrative of how a system behaves under various conditions. Use cases help in understanding system behavior and can be used for system testing and validation.

Use cases are a fundamental part of the Unified Modeling Language (UML). Here are the key aspects of use cases:

Definition:

• Use Case: A use case is a description of a specific way a system interacts with an external entity (an actor), typically to accomplish a goal.

Components of a Use Case:

• Actor: An actor is an external entity (a user or another system) that interacts with the system.
• Use Case Name: A descriptive and meaningful name for the use case.
• Description: A detailed description of the specific interactions and steps involved in the scenario.
• Preconditions: Conditions that must be true before the use case is executed.
• Postconditions: The conditions that should be true after the use case is completed.
• Flow of Events: A step-by-step description of how the interaction proceeds.

We can classify use cases into primary and secondary refer to different levels of importance or centrality within a system. Here's the difference between them:

Primary Use Cases:

• Definition: Primary use cases are essential and represent the main or core functionalities of a system.
• Importance: They are critical to achieving the primary goals and objectives of the system.
• Focus: Primary use cases typically address the fundamental needs and main features that the system is designed to provide.
• Examples: In an e-commerce system, primary use cases might include "Place Order," "View Product Catalog," or "User Authentication."

Secondary Use Cases:

• Definition: Secondary use cases are complementary to the primary use cases and may not be as central to the core functionality of the system.
• Importance: While not critical to the primary goals, secondary use cases enhance or provide additional features to the system.
• Focus: Secondary use cases often address functionalities that, while valuable, are not indispensable for the basic operation of the system.
• Examples: In the same e-commerce system, secondary use cases could be "Product Recommendations," "User Reviews," or "Save Items to Wish list."

In summary, primary use cases are vital for the core functionality and success of the system, while secondary use cases contribute additional, often desirable, features that enhance the overall user experience but are not strictly necessary for the system's primary objectives.

Finally here is my attempt to express the requirements for a health and fitness application using use-cases.

Primary Use Cases:

a. User Registration:
- Description: Allows a new user to create an account by providing necessary information.
- Actors:
New User, System
- Preconditions:
The user has not a registered account on the Health and Fitness application.
- Flow:
User enters registration details.
System validates information.
User account is created.


b. Activity Tracking:
- Description: Enables users to track daily activities like steps, distance, and calories burned.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User initiates activity tracking.
System captures and displays real-time activity data.
User can view historical activity trends.


c. Workout Planning:
- Description: Provides personalized workout plans based on user's fitness goals.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User sets fitness goals.
System recommends tailored workout plans.
User follows suggested exercises.


d. Nutritional Guidance:
- Description: Offers nutritional information and suggests meal plans.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User provides dietary preferences.
System generates personalized meal recommendations.
User can log consumed meals.


e. Social Integration:
- Description: Allows users to connect with friends, share achievements, and participate in challenges.
- Actors: User, Friends, System
- Preconditions:
The user has logged into the application.
- Flow:
User connects with friends.
User shares achievements and goals.
Users participate in challenges.
        

Secondary Use Cases:

a. Real-time Monitoring:
- Description: Monitors user's heart rate during workouts.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User initiates real-time heart rate monitoring.
System displays heart rate data.
User receives alerts for abnormal heart rates.


b. In-App Challenges:
- Description: Allows users to join and participate in in-app challenges.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User views available challenges.
User joins selected challenge.
System tracks and displays challenge progress.


c. Performance Analytics:
- Description: Provides detailed analytics on user's fitness performance.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User accesses performance analytics section.
System presents data trends and achievements.
User receives personalized insights.


d. Emergency Support:
- Description: Facilitates quick access to emergency support features.
- Actors: 
User, System
- Preconditions:
The user has logged into the application.
- Flow:
User activates emergency support.
System sends alerts and location to predefined contacts.
Emergency contacts receive information.        

By creating the Use Cases in a textual version we usually find similar sub-sequences in different use cases, this makes it difficult to "visualize" the complex relationships (including alternatives, extensions, etc.)

More generally, we lose sight of the overall actor/system interactions, focusing instead on the details of a single interaction.

The graphic form remedies these problems very well.

Here are the use case diagrams for our example.

My opinion is that for use cases the graphic form is secondary to the textual one and in any case I prefer to have both.

One of the greatest benefits of the use-case technique is that it builds a set of assets that can be used to drive the testing process.

In fact Use cases can directly drive the development of test cases (1.) :

• The scenarios of a use case create templates for individual test cases.
• Adding data values completes the test cases.
• Testing non-functional requirements completes the testing process.

Jumping to conclusions, one might assume that the use case is itself a test case and that the team can go right to work testing use cases immediately. Well, not exactly. Now I will show you how a fair amount of test design work still needs to be done. Although use cases actually drive this process, some serious analytical work has to be done to convert these assets into the proper stage for system testing.

As an example I took two new use cases of our health and fitness application for personal devices. I tried to detail in depth the scenarios of these two use cases (Basic Flow, Alternative Flow, Exceptional Flow) with the aim of making mapping into the respective test cases easier.

Use Case: Initiates Workout Session

- Description:
The user initiates a workout session through the Health and Fitness application, leveraging the comprehensive features designed to enhance their exercise experience.

- Actor: 
User

- Preconditions:
The user has a registered account on the Health and Fitness application.
The user has logged into the application.

- Basic Flow:
1. The user accesses the main dashboard of the Health and Fitness application.
2. Within the dashboard, the user navigates to the "Workouts" section.
3. The user selects the type of workout they want to initiate (e.g., cardio, strength training, flexibility).
4. The application presents a list of available workout routines or allows the user to customize their session.
5. The user selects a specific workout or creates a custom routine by choosing exercises, durations, and intensity levels.
6. Upon confirmation, the application provides a brief overview of the selected workout, including the estimated duration and intensity.
7. The user starts the workout session.

- Alternative Flow:
If the user has predefined workout plans, they can choose from their saved routines without customizing each session.

- Postconditions:
1. The workout session is initiated, and the application begins tracking relevant metrics.
2. The user can view real-time feedback, including time elapsed, calories burned, and exercise completion status.
3. Upon completion, the application may prompt the user to provide feedback or rate the workout.

- Exceptional Flow:
If there are technical issues or disruptions during the workout session (e.g., loss of connectivity), the application should provide appropriate error messages and allow the user to resume or restart the session.

Note:
This use case outlines the primary scenario where a user initiates a workout session. Additional features, such as social sharing or integration with wearable devices, could enhance the overall user experience.        

Use Case: User Ends Workout Session

- Description:
The user concludes an ongoing workout session within the Health and Fitness application, finalizing the tracking and recording of exercise metrics.

- Actor: 
User

- Preconditions:

1. The user has an active workout session in progress.
2. The application is functioning correctly.

- Basic Flow:
1. The user, during an ongoing workout, decides to conclude the session.
2. Within the workout interface, the user selects the "End Session" or a similar option.
3. The application prompts the user to confirm their decision to end the workout.
4. Upon confirmation, the application stops tracking the workout metrics and concludes the session.
5. The user is presented with a summary of the completed workout, including key metrics like duration, calories burned, and any achievements.

- Postconditions:
1. The workout session is officially ended, and the recorded data is saved in the user's workout history.
2. The application may provide post-workout recommendations, such as stretches or cooldown exercises.
3. The user can review their workout history, including details of the session just completed.

- Alternative Flow:
If the user attempts to end the workout accidentally, the application should include a confirmation step to prevent unintentional session closures.

- Exceptional Flow:
If there are technical issues during the process (e.g., data not saved), the application should notify the user and attempt to recover or store the data securely.

Note:
This use case focuses on the user's ability to consciously conclude a workout session. Integrating feedback mechanisms or additional post-workout features could further enhance user engagement and satisfaction.        

So let's see how these two use cases can be mapped into their respective test cases:

Test Cases for "Initiates Workout Session"

Primary Use Case: User Initiates Workout Session

- Actor: User

- Preconditions: User is logged in, the device is operational, and the application is open.

- Trigger: User selects "Start Workout" from the main menu.

- Test Cases:

1. Test Case: Verify Workout Initialization
Steps:
1.1 User selects "Start Workout."
1.2 Ensure the application initializes the workout session.
1.3 Verify that the device captures baseline health metrics.

2. Test Case: Validate Real-time Data Monitoring
Steps:
2.1 During the workout, confirm that real-time data (heart rate, distance, etc.) is accurately displayed.
2.2 Ensure data updates are consistent with the user's activity.

3. Test Case: Check Pause and Resume Functionality
Steps:
3.1 User pauses the workout.
3.2 Confirm the application accurately pauses data recording.
3.3 User resumes the workout.
3.4 Verify the application resumes recording without data loss.
        

Test Cases for "User Ends Workout Session"

Secondary Use Case: User Ends Workout Session

- Actor: User

- Preconditions: User is engaged in an active workout session.

- Trigger: User selects "End Workout" from the workout screen.

- Test Cases:

1. Test Case: Confirm Workout Termination
Steps:
1.1 User selects "End Workout."
1.2 Verify the application accurately concludes the workout session.
1.3 Check that the recorded data is saved.

2. Test Case: Review Post-Workout Summary
Steps:
2.1 After ending the workout, confirm the application displays a summary of the session.
2.2 Validate the accuracy of post-workout metrics and achievements.

3. Test Case: Share Workout Results
Steps:
3.1 User selects the option to share workout results.
3.2 Ensure the application correctly initiates sharing functionality.
3.3 Confirm that shared content reflects the accurate workout details.        

These are simplified examples, and actual test cases would include more detailed steps, expected results, and validation criteria. The goal is to illustrate how each use case can be translated into specific test cases to ensure the functionality of the health and fitness application.

I would like to end this article with my final thoughts on requirements representation:

• Project Nature: The choice between these techniques often depends on the nature and scope of the project. Larger, more formal projects may benefit from a detailed requirements document, while agile projects might favour user stories.
• Stakeholder Involvement: User stories excel in engaging stakeholders, while use cases offer a balance of detail and structure.
• Adaptability: User stories and use cases, being more adaptable, are better suited for dynamic projects with evolving requirements.
• A hybrid approach, combining elements of user stories and use cases, might be beneficial for projects seeking both adaptability and structured detail.

?

That's all about Requirement, Use cases and user story.

See you on the next episode.

?

I remind you my newsletter "Sw Design & Clean Architecture"? : https://lnkd.in/eUzYBuEX where you can find my previous articles and where you can register, if you have not already done, so you will be notified when I publish new articles.

Thanks for reading my article, and I hope you have found the topic useful,

Feel free to leave any feedback.

Your feedback is very appreciated.

Thanks again.

Stefano

?

References:

1. Leffingwell, Widrig, “Managing Software Requirements: A Use Case Approach”- Addison Wesley (February 2013) - chapters 1,2,3,4,5,6,14.

2. K. Wiegers, “Software Requirements”, Microsoft Press (2003) - chapters 1,2,3,4.

3. Sommerville, "Software Engineering", Ninth edition, Addison Wesley (2011). pp 205-233. - chapter 8.

4. Robert Martin, "Clean Agile", Pearson (2019).

?