Welcome to Week 6 of an introduction to medical software class. In this week segments, we're going to talk about user needs and the system requirements specification. These are the first two steps in the medical software life-cycle. The goals of this lectures is precisely to discuss user needs and the process of how we go about identifying them, how we go about writing a systems requirements, and coming up with what they should be. We're going to show examples for our project image guided neurosurgery project of both the user needs process and the systems requirements process. There are six segments in this week, the first two are we discuss about how we go about identifying user needs. Then we'll talk about usernames for a specific image guided neurosurgery example project, then we'll talk about the system's requirement specification, we'll give you a template for that, one that I developed for my teaching needs, and then in the last segment, we'll talk about the system requirements specification for our image guided neurosurgery project. This week's materials is based on Chapters 11 and 12 of the textbook, and we'll keep returning to the book as we go through. In this and the next segment, we're going to talk about the process of identifying user needs. While there are structured processes here that people use and there are people who are business analysts, some as of guidelines and checklists, a lot of this is in fact experience. You just learn by doing, and so a lot of the material you see in the next few slides are checklists, things to do, things to not forget, and these are from my own experience and the experience of my colleagues who I talked to as I was preparing this class. This is the V-model, we made it in Week 1 and we're going to use this for the next few weeks as we go through the process, where in step 2 here, where in the use cases, we are going to visit our users and figure out what is it that they need. This is our task, and this is a definition I came up with over the years of teaching. Our goal is to translate the often vague and amorphous user wishes to a plan of action that can result in a successful and robust software product that integrates into the user's environment and allows her to accomplish the task that she needs to do. That's my definition of what the goal of user needs are. When you talk to your users, this is the problem we deal with often, their needs are in more faster vague. I need something that lets me do this. But your job as an engineer here, as a designer is to take those somewhat vague statements and make them into concrete, detailed specifications that allow you to create software computers' need details. There's no software project, there's no computer program that takes vague instructions. You have to get it down to a set of rules effectively that will let you proceed. Many people are not used to operating at this level of detail, they tell you what they need, but our Java software engineers is to get from that vague statement of this, I wish I had something that let me do this to very detailed flowchart, almost set of rules that let us create software. We have some regulatory constraints here as always. As you proceed with your discussion, with your users to identify what are their needs, you should ask and keeping in mind how one would demonstrate efficacy that a software achieves its intended uses, safety, that we do not cause harm to the patient or to the caregiver as part of using our software, and security, that a software cannot be abused for malicious purposes, think about cybersecurity here. We also have to be mindful of data privacy issues if they are applicable depending on what exactly a software is doing. In all designed, and this applies to software design and identifying user needs, we also have this tension between what and how. What is the abstract, the actual objective of the user? If we go back to the lawn example, the objective of the user, they would like to keep their grass short. The how, the concrete is the method used to accomplish this. We use a lawn mower to mow the lawn. We have to operate on both of these planes: what, at the abstract planes where we understand what needs to happen, and how, the concrete plane is where we actually do it. At the end of the day, you have to have a lawn mower or some piece of equipment or a drug, or a piece or tool or something that will actually be applied to this situation. This leads to a discussion of what's called The Brown Cow Model. This comes from a book called Mastering the Requirements Process from Robertson and Robertson, you can see the cover on the top left of the slide. This model illustrates well the tension between the how and the what. At the bottom, we start with how now the model of the currency situation, what is the user actually doing right now? Concrete. We move up to a more abstract level. "What now". The essential business use case, what are they actually trying to do as opposed to what they're doing. This line here, think about this horizontal line that divides between the concrete, the real-world, and the abstract, the world of ideas and designs if you wish, and it will go from how, towards. The process starts, how, I login and my user is in a lawnmower, but what are they trying to do? They're trying to keep the grass short. Then we often, and this is a Brown Cow model, ask the next question, what future, what is the enhanced present? What else would my user would like to have to do, not only what they're doing now, maybe that's enough. Can I get them to do what they do know better, but they will often have additional wishes. Then we return down to the real world. How future? What is the product use case scenarios? How's the product going to be designed to implement this new idea, this new functionality? There is this tension, your users often leaving the abstract world. They tell you what they need, you have to work as a software engineer about the concrete world, and so this interplay between the abstract and the concrete is a fundamental challenge. This is the routine, we go from "how" to "what", to "what" to "how". The first step in the process of any kind of medical software project is to understand the problem area. You have to learn something about the clinical problem and the current approaches to solving it. Something about the disease, the anatomy and the physiology of the disease, something about the current procedures for diagnosis, treatment, or whatever it is you're trying to do. Let's say you're developing software to do cancer screening for mammography to automatically analyze mammography images that are used to screen women for breast cancer. You want to know something about the disease, which breast cancer, how it manifests itself, and what are the current procedures for the task you're trying to do? Well, currently, they call the mammography this way and they are running through this piece of software, I guess there are some measurements, and based on that, that makes some sense. You won't understand the how now effectively, and then from that to abstract it out to understand why they're doing what they're doing. The second part of the processes that you want to know something about the patients. What is their age? What is their sex? Do they have obesity or other issues? Are there are other diseases that are involved? Because this will help you understand a little bit about how your software will be used. You want to understand a little bit about the problematic, that's usually step 1. The other thing, as we end this section and we'll pick up the story in the next segment, is you want to learn a little bit about working with clinicians. You have to establish common language, and you as a technical person, you need to have first some key vocabulary about the disease. Both you and your clinical partner will need to crossover, but in practice, you will not meet in the middle but closer to the clinical side. If this is the medical world and this is the software world, and this is the mid-line, you're going to meet somewhere here, closer to the clinical world than to the software. You as a technical person will have to learn more about what they do than they will learn about what you do. If you find a physician that wants to know a lot of details about what you do, that may end up being a very valuable collaborator. Those people are rare. The other thing to keep in mind, and we'll return to this in the next segment as well, is it remember that physicians, and to put it sensitively, are often headstrong character set. They operate in a medical environment, they are used to telling people what to do and to be obeyed. They have a very strong sense of what needs to happen because that's what they need to be able to do. They need to tell people how to take difficult decisions and make adjustments to their lives in order to overcome some medical problem. You have to keep that in mind and not confuse it with an instruction. You have to separate out what they know and what they don't know, and to listen to them in those aspects that they are good at, and to learn to ignore a little bit when they get you into technical details where they don't necessarily have the expertise, but they're still used to speaking without a photographic voice. That concludes this first segment on user needs, we'll continue the discussion with more checklists and more advice in the next segment.
