By using this site, you agree to the Privacy Policy and Terms of Use.
Accept
Health Works CollectiveHealth Works CollectiveHealth Works Collective
  • Health
    • Mental Health
  • Policy and Law
    • Global Healthcare
    • Medical Ethics
  • Medical Innovations
  • News
  • Wellness
  • Tech
Search
© 2023 HealthWorks Collective. All Rights Reserved.
Reading: How to Tackle Vague Requirements in Health IT and Medical Device Software
Share
Notification Show More
Font ResizerAa
Health Works CollectiveHealth Works Collective
Font ResizerAa
Search
Follow US
  • About
  • Contact
  • Privacy
© 2023 HealthWorks Collective. All Rights Reserved.
Health Works Collective > Technology > Medical Devices > How to Tackle Vague Requirements in Health IT and Medical Device Software
Medical DevicesTechnology

How to Tackle Vague Requirements in Health IT and Medical Device Software

ShahidShah
ShahidShah
Share
7 Min Read
Health IT
SHARE

Health IT

Health IT

These days it’s pretty easy to build almost any kind of software you can imagine — what’s really hard, though, is figuring out what to build. As I work on complex software systems in government, medical devices, healthcare IT, and biomedical IT I find that tackling vague requirements is one of the most pervasive and difficult problems to solve. Even the most experienced developers have a hard time building something that has not been defined well for them; a disciplined software requirements engineering approach is necessary, especially in safety critical systems.

One of my colleagues in France, Abder-Rahman Ali, is currently pursuing his Medical Image Analysis Ph.D. and is passionate about applying computer science to medical imaging to come up with algorithms and systems that aid in Computer Aided Diagnosis (CAD). He’s got some brilliant ideas, especially in the use of fuzzy logic and storytelling to elicit better requirements so that CAD may become a reality some day. I asked Abder-Rahman to share with us a series of blog posts about how to tackle the problem of vague requirements. The following is his first installment, focused on storytelling and how it can be used in requirements engineering: 

More Read

Disrupting and Destructing Healthcare
Meeting the Challenges of a Slowing Metabolism
Kinect Technology Saves Having to Rescrub!
Device Separates Stem Cells During Surgery for PAD Treatment
Marketing Medical Devices to Consumers, Not Patients

I remember when I was a child how my grandmother used to tell us those fictional and non-fictional stories. They still ring in my ears, even after those many years that have passed by. We used to just sit down, open our ears, stare our eyes, move around with our thoughts, and we don’t get out of such situation until the story ends. We used to make troubles sometimes, and to get us calm, we were just being called to hear that story, and the feelings above came to use again.

Phebe Cramer, in her book, Storytelling, Narrative, and the Thematic Apperception Test, mentions how storytelling has a long tradition in human history. She highlights what have been considered the significant means by which man told his story. Some of those for instance were the famous epic poems, the Iliad and the Odyssey from the ninth century B.C., the Aeneid from 20 B.C., the east Indian Mahabharata and Ramayana from the fourth century A.C., …etc. This is how history was transmitted from one generation to the other.

Storytelling Tips and Tales emphasizes that stories connect us to the past, and enlighten for us the future, lessons can be learned from stories, and information is transmitted transparently and smoothly through stories. Teachers in schools are even being encouraged to use storytelling at their classrooms. The books also believes that storytelling is an engaging process that is rewarding for both the teller and the listener. Listeners will like enter new worlds by just hearing the words of the teller. Schank and Abelson even see that psychological studies have revealed that human beings learn best from stories, in their Knowledge and Memory: The Real Story.

Having mentioned that, a requirements engineer may ask, why couldn’t we just then bring storytelling to our domain? Especially that in our work, there would be a teller and a listener. Well, could that really be?

Let us examine the relationships between story elements and a software requirement in order to answer that question.

In his book, Telling Stories: A Short Path to Writing Better Software Requirements, Ben Rinzler highlights such relationships as follows (some explanations for the points was also used from Using Storytelling to Record Requirements: Elements for an Effective Requirements Elicitation Approach):

  1. Conflict: This is the problem you want to solve in the requirements process. An example of that is the conflict that occurs between stakeholders needs and the FDA regulatory requirements for some medical device software.
  2. Theme:  This is the central concept underlying the solution. For requirements engineering, this could be a “requirement”, that is, the project goal.
  3. Setting: Knowing that the setting is the place and time of the story. In requirements engineering, this can be stated as the broader concept of the problem at hand, such as providing information about the technology environment, business, …etc.
  4. Plot: The plot of a story is its events that occur in a certain order, such that their outcome affects later once. In requirements engineering, this is the current and future systems’ series of actions.
  5. Character: This refers to any entity capable of action. In requirements engineering, this can for instance represent people, machines, and programs.
  6. Point of view: Having different points of view is important for providing a unified view that tries to provide a whole description of what is actually happening, and what everyone needs. This is like describing a medical device software process from the patient and physician points of view for instance.

So, yes, a relationship and an analogy exists between storytelling and software requirements.

In future posts in the series, Shahid and I will dig more deep on how storytelling could be employed in the requirements engineering process, and will also try to show how can fuzzy logic be embedded in the process to solve any issues that may be inherent in the storytelling method.

Meanwhile, drop us comments if there are specific areas of requirements engineering complex software systems that you’re especially interested in learning more about.

health IT / shutterstock

Share This Article
Facebook Copy Link Print
Share

Stay Connected

1.5kFollowersLike
4.5kFollowersFollow
2.8kFollowersPin
136kSubscribersSubscribe

Latest News

dental care
Importance of Good Dental Care for Health and Confidence
Dental health Specialties
October 2, 2025
AI in Healthcare
AI in Healthcare: Technology is Transforming the Global Landscape
Global Healthcare Policy & Law Technology
October 1, 2025
Choosing the Right Swimwear for Health and Safety
News
September 30, 2025
sports concussions
Concussion In Sports: How Common They Are And What You Need To Know
Infographics
September 28, 2025

You Might also Like

uber-phone.jpg
eHealthHospital AdministrationMedical InnovationsTechnologyWellness

How Hospitals Are Using Technology to Improve Patient Access to Care

September 21, 2016

RSNA 2013: What Does the Power of Partnership Really Mean?

December 13, 2013

Synthetic Cartilage Implant Designed to Restore Natural Joint Mechanics

July 19, 2013

Changing Behavior to Conquer Obesity

September 23, 2012
Subscribe
Subscribe to our newsletter to get our newest articles instantly!
Follow US
© 2008-2025 HealthWorks Collective. All Rights Reserved.
  • About
  • Contact
  • Privacy
Welcome Back!

Sign in to your account

Username or Email Address
Password

Lost your password?