Module IV
IoT Use Case Development
Approaches to gather business requirements, defining problem statements, business
requirements for use case development, Assets for development of IoT solutions.
By
Dr Shola Usha rani
SCOPE VIT
Introduction
• IOT system is complex, challenging involves many interactions among
various components.
• Network resources, web services, analytical components applications and
database servers.
• System with specific products/services
• Design should be specific to choice of products/services to use.
• General design methodology for IoT system design independent of
specific product and programming language.
Gathering business requirements
• What the end customer wants??
• Why they need to buy your product??
• Transformation in mobile usage
• Transformation in social media technologies
• Current market needs
Business requirements gathering methods
• Brainstorming
• Gathering list of ideas and solutions around a specific domain of interest .
• One on One Interviews
• Group Interviews
• Questionnaires
• Workshops
• Joint Application Development
• Prototyping
• Use Cases
• User Stories
Brainstorming
➢ Brainstorming is a simple way to
gather requirements.
➢ It is a group creativity
technique by which efforts are
made to find a conclusion for a
specific problem by gathering a
list of ideas spontaneously
contributed by the members.
➢ Subject matter experts gather in a room
with project team members and start
brainstorming about ideas – good, bad or
indifferent.
➢ an promote creative thinking,
bring a team together, and help
you land on the perfect idea
➢ There are several brainstorming techniques.
Brainstorming Methods
• Nominal group technique: getting ideas randomly, collect all ideas, voting
the idea, finalize the best idea.
• Group passing technique : write the question or requirement, pass this to
group of people, new ideas are obtained, fine tuned the final best idea.
• Team idea mapping method : getting all ideas from each individual, finally
all ideas are mapped.
• Directed brainstorming :already solution is known, question will be given
asked each induvial to write the response, will passed to all, all ideas on
paper are randomly swapped among all participants. Three or four rounds
will be taken.
• Guided brainstorming
• Individual brainstorming
• Question brainstorming
One on One Interviews
➢One of the easiest ways for requirement gathering is to
ask the users what they need.
➢The task of the business analysts is to help
business find a solution for the problem.
➢It is better to plan the interview, so you know what you
are looking for.
➢What you must do is first ask open-ended questions.
➢Once the user starts talking, ask the questions that
will expose the requirements.
Group Interviews
➢Another great way to gather requirement is through
group interviews.
➢This technique is like one on one interview.
➢The only difference is that in group interview more
than one person is being interviewed.
➢You can benefit from group interviews if everyone is on
the same level. (leadership meetings).
➢You must be more prepared when conducting a group
interview.
➢If the team is focused, you will gather requirement in
a shorter span of time.
➢ Meeting with sales people, group heads and leaders etc.,
Questionnaires
➢ Questionnaires is another possible way to gather requirements.
➢ They are ideal for gathering requirements from hundreds of
people in a compressed period.
➢ You must make sure the questions are structured correctly.
➢ Using open-ended questions is good.
➢ Open-ended questions are questions that cannot be answered with a simple "yes"
or "no" response.
Workshops
➢ One of the business requirements methods is having
facilitated sessions.
➢ In this, you gather a group of people for a common purpose.
➢ This technique is best for gathering requirements that are
common.
➢ By conducting workshops or conferences, you can gather requirement faster
Joint Application Development
➢ Another good technique is Joint Application Development.
➢ These are just like the facilitated sessions but with a slight difference.
➢ The session is not over until the objectives are met.
Prototyping
➢ Prototyping is an easy way to gather requirements.
➢ The project team compiles the requirements and creates a
clickable prototype of the product.
➢ Then the users can see the concept in action and be able to provide
constructive feedback.
Use Cases
➢ Use Cases are another way to define business requirements.
➢ It can be simple or complex, depending on the depth of information
being sought.
➢ Many a time, teams focus on the “happy path, ” and that leads to a lot of
unhappy outcomes.
➢ Irrespective of which business requirement gathering method one uses,
it would behave us to avoid the common pitfalls by starting out of the
gate with a set of pre-created customizable project requirements.
User Stories
➢ User stories are a particular form of requirements documentation methods,
applicable to Agile development methodologies.
➢ A user story expresses a specific activity in the voice of the user.
➢ user stories that can help capture user’s requirements holistically and
encompass the needs of your customers
How to Write a Problem Statement
➢What it is?
➢A problem statement is usually one or two sentences to explain the problem
your process improvement project will address.
➢In general, a problem statement will outline the negative points of the current
situation and explain why this matters.
Why Problem Statement?
➢One of the most important goals of any problem statement is to
define the problem being addressed in a way that's clear and
precise.
➢Its aim is focus the process improvement team’s activities and steer
the scope of the project.
How Problem Statement?
➢Creation of a problem statement is an activity that is best completed in a small
group.
➢It is helpful to have a couple of people who are involved in the process and a
process owner involved in the activity.
➢ Get each person to write his or her own problem statement without conferring. Compare
each of the sentences/ looking for common themes and wording.
➢ Start to write an improved statement using the common themes.
➢ Ensure that the problems include the customer’s perspective
How Problem Statement?
➢ Ensure that the statement focuses on existing problems.
➢ Try to include the time frame over which the problem has been occurring.
➢ Try to quantify the problem. If you do not have the data to hand, defer writing the final
problem statement until you have been able to quantify the problem. You should be able
to apply the 5 'W's (Who, What, Where, When and Why) to the problem statement.
➢ A problem statement can be refined as you start to further investigate root cause.
➢ Finally, review your new problem statement against the following criteria:
➢ It should focus on only one problem.
➢ It should be one or two sentences long.
➢ It should not suggest a solution
Example of Problem Statement
• Collision risk estimation in airspace and mathematical modeling of mid-air
collisions have been carried out. There has been a development of
mathematical models for processes leading to possible collisions of aircraft
flying nearby in order to estimate the risk of collision.
• In air-traffic control, possibility of collision between two air crafts, we
should monitor the planes that come to close together.
• This will be solved by giving an array of n points in the plane of region, and the
problem is to find out the closest pair of points in the array that causes aircraft clash.
User Stories
➢ User stories are a particular form of requirements documentation methods,
applicable to Agile development methodologies.
➢ A user story expresses a specific activity in the voice of the user.
➢ user stories that can help capture user’s requirements holistically and
encompass the needs of your customers
User Story Example
Since the beginning of aviation, human error has been recognized as a major
factor in accidents and incidents. Indeed, one of aviation’s biggest challenges
has been — and will continue to be — human error avoidance and control.
Traditionally, human error in aviation has been closely related to operational
personnel, such as pilots, controllers, mechanics, dispatchers, etc.
Contemporary safety views argue for a broadened perspective which focuses
on safety deficiencies in the system rather than in individual performance.
Evidence provided by analysis from this perspective has allowed the
identification of managerial deficiencies at the design and operating stages
of the aviation system as important contributing factors to accidents and
Brainstorming activity
• Brainstorming
• to help you come up with an innovative IoT project
• Ask yourself or goals to consider:
• What inefficiencies exist in daily life or industries?
• How can IoT improve automation, safety, or efficiency?
• Devices/controllers
• Gateway
• Edge device computing
• Cloud API and Application Interface
• Nominal group technique: getting ideas randomly, collect all ideas, voting the idea, finalize
the best idea.
• Group passing technique : write the question or requirement, pass this to group of people,
new ideas are obtained, fine tuned the final best idea.
• Team idea mapping method : getting all ideas from each individual, finally all ideas are
mapped.
• Directed brainstorming :already solution is known, question will be given asked each
induvial to write the response, will passed to all, all ideas on paper are randomly swapped
among all participants. Three or four rounds will be taken.
Each Activity
• Moderator Name:
• Title of the work
• Team members
• Activity Explored:
• Output/summary of Solution
Example
• Example Problem Areas:
• Energy waste in homes and offices (A1)
• Poor air quality in urban areas
• Difficulty tracking assets in warehouses
• Inefficient water usage in agriculture (A2)
Business requirements for IoT
use case development
• When developing use cases for an Internet of Things (IoT)
application, the business requirements must reflect the unique
aspects and challenges of IoT systems.
• How to consider business requirements specifically for IoT use
case development:
1. Connectivity Requirements
2. Data Collection and Processing
3. Device Management 8. Reliability and Availability
4. Security and Privacy 9. Legal and Regulatory
5. User Interaction Considerations
6. Scalability 10. Performance Metrics
7. Interoperability 11. Cost Considerations
1. Connectivity Requirements
- Network Availability: Specify the type of networks the
devices will connect through (e.g., Wi-Fi, 5G, LPWAN).
- Bandwidth Constraints: Determine the data bandwidth
requirements for the devices and how they manage during
limited bandwidth.
- Persistent Connection Needs: Establish whether
devices need to be always connected or if intermittent
connectivity is acceptable.
2. Data Collection and Processing
- Data Volume: Define the amount of data that will be
collected by IoT devices.
- Data Frequency: How often data is collected and at
what intervals.
- Data Processing: Specify where the data will be
processed – on the device itself (edge computing), in
the cloud, or a hybrid approach.
- Data Accuracy and Quality: Ensure the precision of
sensors and data collection methods meet the required
standards.
3. Device Management
- Device Provisioning and Deployment: Outline how
devices will be added, configured, and maintained.
- Remote Management: Specify the capabilities for
remote monitoring, updating, and troubleshooting of
devices.
- Lifecycle Management: Define how long devices are
expected to operate and the process for their
retirement and replacement.
4. Security and Privacy
- Authentication and Authorization: Determine how
devices will be securely identified and what access they will
have.
- Data Security: Plan for encryption of data in transit and
at rest.
- Compliance: Identify and incorporate necessary
compliance standards for data privacy, such as GDPR for
European users.
- Device Security: Protect devices from physical tampering
and ensure secure firmware updates.
5. User Interaction
- User Interface: Design how users will interact with the IoT
system, including mobile apps, web portals, or integrated voice
controls.
- User Experience: Ensure a seamless, intuitive user experience
that aligns with user expectations and the specific environment
of the IoT application.
6. Scalability
- System Scalability: Define how the system will handle an
increasing number of devices and data volume.
- Future Expansion: Consider how new device types or
functionalities might be added to the system.
7. Interoperability
- Integration with Other Systems: Specify how the
IoT application will integrate with existing systems
and data sources.
- Standards Compliance: Follow industry standards
to ensure compatibility and interoperability between
different devices and systems.
8. Reliability and Availability
- Uptime Requirements: Define the expected availability
of the IoT system.
- Fault Tolerance: Establish how the system will handle
device failures or network disruptions.
9. Legal and Regulatory Considerations
- Regulatory Compliance: Account for industry-specific
regulations that apply to IoT devices and their
deployment.
- Legal Requirements: Ensure that all legal aspects, such
as warranties and liabilities for device failure, are
addressed.
10. Performance Metrics
- Success Criteria: Set clear performance indicators
for the IoT system that tie back to the business
objectives.
11. Cost Considerations
- Budget Constraints: Define the budget for
development, deployment, and maintenance of the IoT
system.
- ROI Analysis: Outline the expected return on
investment and how it will be measured.
User Story and use cases
user stories set a foundation upon which use cases are created or developed.
user stories try to explain to the engineering team about the environment,
goal, role, intention of the user while he/she is going to deal or work with
the software;
User stories will be given by product manager
use cases clearly define what the user is going to do here and what result is
expected in crisp 2-3 lines.
Use cases are one level above requirements.
Use cases & user stories
User stories Use cases
• Helps to develop better products. • simple words are exact statements
• A short story depicting an written in informal manner depicting
environment consisting of one or the specific action that the user is
more users working with software. expected to do while dealing with a
particular functionality of the product.
• User interactions give rise to user
stories • Acts as a guiding statement to develop
requirements for engineering teams
• A very specific statement depicting an
user action with an expected outcome
Ready-made, Customizable Business
Requirements
• Human Resources transformation business requirements span Core HR, Payroll,
Benefits Administration, Workforce Planning, Applicant Tracking, Performance
Management, Talent Management and related areas.
• CRM Transformation business requirements span client contact management, lead
management, opportunity management, sales forecasting, pipeline management, Catalog
management, order management, customer interaction tracking, activity management and
related areas.
• Supply Chain Transformation business requirements span procurement networks, e-
sourcing, logistics, warehousing, distribution, vendor management and related areas.
• Business Intelligence Transformation business requirements span data management,
data analysis, data visualization, algorithms, predictive analytics, dashboards and
associated areas.
• Marketing Transformation business requirements span advertising, social media
management, collateral management, web analytics, email marketing and related areas.
• Accounting and Finance Transformation business requirements span general ledger,
accounts payable, accounts receivable, treasury management, regulatory compliance,
capital budgeting, decision support and related areas.
Uses of Requirements
Failed to accurately translating the use
stories and use cases to proper
requirements will lead to failure of the
engineering team
What is a requirement
Requirements as a clear concise
sentence of not more than 10 words
specifying the most singular unit of
demand.
Generating requirements
• To track the use cases and user stories.
• Requirements are created from use cases.
• It is documented and recorded to ensure the correctness of the job
that performed.
Guidance for Generating Requirements
Requirements should be concise and should contain only one demand in them.
A single use case should not be giving rise to more than 2, at max 3, requirements.
If a use case is able to generate more than 3 requirements then it is a clear sign that
this use case is in fact a half-baked user story and needs to be broken down further.
If a requirement cannot be expressed in less than 10 words then it is a use case in
disguise and you need to relook at your user stories once again
All requirements should have priority.
Requirement Traceability
Requirement number has to be unique and will be used to track the requirement in various forums,
discussions and work breakdown structures. Recommended format for requirement number is X.Y
where X refers to the use case number and Y refers to the unique requirement within that use case. For
example: 1.1, 1.2, 1.3 and so on to depict 1,2,3 requirements for use case 1.
Requirement description as we know is a clear concise sentence of less than 10 words depicting a
single unit of demand.
Use case generated from allows the product manager and engineering team to know which use case
generated this particular requirement and suppose, down the line if use case or user story undergoes
modification then we will clearly know which requirements are impacted and require a review.
So it helps in that sense.
Business priority is not to be confused with task priority. Every task that is a child of a requirement will
have its’ priority depicting the order in which they should be done.
Creating Requirements from use cases
and are from use stories
Example of User story-Tooth paste
• It is 6:30AM in the morning and John has started his morning services to be ready for
work. Daily, his first routine after waking up is to brush his teeth with his favorite
toothbrush so that he gets the refreshing feel to do remaining chores around the house
and leave for work on time. He likes the way toothpaste, smoothly oozes out of the tube
and rests firmly on this toothbrush without spilling anywhere. Also he likes that
somehow, every time he brushes, the exact right amount of the paste comes out of the
tube. It is never too much and never too little. It’s just right.
He feels energized after a refreshing brush ritual and likes the feeling of freshness in his
mouth after brushing his teeth. His gums feel rejuvenated, breath feels fresh as he tests
it out on his palms. After spending whole day at office, where he had multiple cups of
coffee, some food and some sugary items, he comes back home. While refreshing
himself, he notices that his breath is still fresh and the taste in his mouth is still neutral
without any traces of coffee or cheese pizza he had before. He is so pleased with the
product that he has bought for himself, that he decides to write about it in his blog
tonight.
Outcome of user story
• Actor : John, a working professional who wants to keep his teeth
health and shiny
Role : The direct consumer of this product can influence others by
his reviews of a product on his website.
Expected results: After brush, John expects his breath to be fresh and
teeth and gums to be health for the whole day.
Use cases for the example
• Use case 1: User wants to have a premium quality feel when he/she takes the
toothpaste tube in their hand before brushing.
Use case 2: User gently squeezes the tube and he is pleased with the smoothness
of the paste flow out of this tube.
Use case 3: User is able to notice the right amount of paste coming out of the
tube every time, he/she brushes. It is never too much nor too little. One gentle
squeeze always gives out the right amount of paste required for brushing.
Use case 4: User feels an air of freshness in his mouth after brushing and that
freshness lasts for minimum of 24 hours. The feeling of freshness is neither
overwhelming nor un-noticeable. It is just mild enough to provide a feeling of
freshness while not interfering with user’s culinary habits.
Use case 5: The user is pleased with the fact that the teeth and gums feel very
smooth and non-scratchy after every brush.
Use case 6: User is happy about the fact that even after 12 hours of intense work
day routine, his breath still feels fresh
Requirements generation with example
Use Case 1: “User wants to have a premium
quality feel when he/she takes the toothpaste
tube in their hand before brushing.”
Use Case 2: “User gently squeezes the tube
and he is pleased with the smoothness of the
paste flow out of this tube”.
Example-II
• User Story: Smart Irrigation System for Efficient Water Management
• Water scarcity and inefficient irrigation practices have been significant
challenges in modern agriculture. Traditional irrigation systems often lead to
overwatering or underwatering, which negatively impacts crop yield, soil
quality, and water conservation. With the rise of the Internet of Things (IoT),
farmers can now leverage smart irrigation systems to optimize water usage,
reduce manual effort, and increase agricultural productivity.
• This IoT-based Smart Irrigation System integrates soil moisture sensors,
cloud-based analytics, and automated irrigation control to ensure crops
receive the right amount of water at the right time. By using real-time
monitoring and automation, the system helps conserve water while
improving crop health and reducing costs for farmers.
Example –II
• Use cases
1. Real-Time Soil Moisture Monitoring
2. Automated Irrigation Based on Soil Moisture Levels
3. Mobile App Notifications for Farmers
4. Manual Control of Irrigation via Mobile App
5. Water Usage Analytics & Reports
Requirements for use case-I
• The sensor reads the soil moisture level.
• Data is sent to the cloud for analysis.
• The farmer can view the real-time moisture levels on a dashboard or
mobile app.
Requirements for use case-II
• The system detects low soil moisture.
• The irrigation pump is automatically activated.
• Water is supplied to the field until the soil moisture reaches the
optimal level (e.g., 60%).
Requirements for use case-III
• The system detects low soil moisture.
• The farmer receives a push notification: "Soil moisture is low in Field
A. Irrigation started.
• Once irrigation completes, another notification is sent: "Irrigation
stopped. Moisture level restored.
Use Case Diagram(use
case development-II)
Use case diagram components
• Actors: The users that interact with a system. An actor can be a
person, an organization, or an outside system that interacts with your
application or system. They must be external objects that produce or
consume data.
• System: A specific sequence of actions and interactions between
actors and the system. A system may also be referred to as a scenario.
• Goals: The end result of most use cases. A successful diagram should
describe the activities and variants used to reach the goal.
Use case diagram symbols and
notation
• Use cases: Horizontally shaped ovals that represent the different
uses that a user might have.
• Actors: Stick figures that represent the people actually employing
the use cases.
• Associations: A line between actors and use cases. In complex
diagrams, it is important to know which actors are associated
with which use cases.
• System boundary boxes: A box that sets a system scope to use
cases. All use cases outside the box would be considered outside
the scope of that system.
• Packages: A UML shape that allows you to put different elements
into groups. Just as with component diagrams, these groupings
are represented as file folders.
IoT Application components
• Actors
• System
• Goals
• Associations
• Communication Protocols
• Communication API
• Cloud part – Modules
• Big data/ analytics
IoT Eco system for Healthcare
Practice Use Case Diagram for Smart
Healthcare
Practice
• IoT design methodology for weather reporting system
• IoT Design methodology for smart farming
• IoT design methodology on smart cities
• IoT design methodology on smart factory
• IoT design methodology on smart energy/smart grid
References
• [Link]
gathering-methods/
• [Link]
[Link]
• [Link]
• Brainstorming –Wikipedia
• User Stories and User Story Examples by Mike Cohn
([Link])
• [Link]
management/how-to-generate-requirements-from-use-
cases
• [Link]
solutions-development/