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

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: 

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