When your users are physicians and nurses, they don't have time to sit in meetings explaining what they want out...
of an application or to wade through documents validating requirements. Patient care is their number one priority.
To get over that obstacle, the development team at the University of Texas M.D. Anderson Cancer Center relies on a simulation tool. Using iRise's visualization tool, physicians and nurses can see what the application will look like based on requirements given and quickly change or validate those requirements.
Those applications are part of an electronic medical record (EMR) ClinicStation that the cancer center has been working on for the past three years, after they could not find a packaged application that met the hospital's unique needs. Sherry Preston, manager of EMR support and development, business analysts at the center, called the project a work in progress that will continue to evolve.
"ClinicStation first started with an X-ray feature that made it so the X-rays were computerized rather than having those big X-rays to send around," she said. "Right now they can enter a patient's information such as medications, allergies, and vital signs. We keep building on to that functionality. We're putting in an order-entry component now so that physicians can order tests for a patient and those will go right to the lab."
Having such a system means paper charts will be eliminated; it will all be electronic, Preston said.
To get to that point means getting their very busy stakeholders -- physicians, nurses, and pharmacists -- to explain what they need the application to do. And wading through Microsoft Word, Excel, or PowerPoint files isn't going to cut it. That's why Preston's department turned to iRise.
Using iRise, the analysts take an existing, as-is workflow and modify it based on what the stakeholders said they want. Then they present the stakeholders with a simulation of what they think they want so that they can validate the requirements.
"This helps them say, 'Oh, no. No, this isn't how we do that. We do it like this.' So we switch things around and move things. And we can do it on the fly. You can do it right there during a meeting," Preston said.
Simulations are good for conversations, she added. They trigger analysts to ask more questions so that the stakeholders get what they really want.
"We have very complex, huge projects that we're working on. With the iRise simulations, very little interpretation is needed. What you see on the screen is what you're getting," Preston said.
Analysts can also send simulations to stakeholders over the Web, and the stakeholders can make suggestions and send it back. The doctors and nurses don't really have time to sit in meetings.
"All of our business analysts like it a lot, and our stakeholders love it. Once they saw it, they don't want paper documents at all," Preston said.
Things to be aware of
Preston warned that stakeholders need to be told that the simulations are to evaluate their workflow. The GUI they see might not be the GUI the programmers give them.
"We don't want stakeholders designing the GUI," she said. "They're deciding functional requirements and business rules."
Having that conversation with the stakeholders can help eliminate concerns developers may have about the stakeholders dictating how they program the application. Both groups need to understand that the simulation tool is there to give the programmers a general idea for the look and feel. It does not generate code.
Mitch Bishop, chief marketing officer at iRise, said that is intentional.
"We don't do that on purpose because [analysts] don't know what code to generate -- they don't know what language," he said.
Preston said the analysts review the simulations with the programmers, and they've come to depend on them. Bishop further said even "hardcore developers" like it because it communicates what people want, whereas text can be interpreted in many ways.
"It forces the business to articulate what they want in a language everyone can understand," he said.
Preston also cautioned about the drain simulations have on computer memory. If you don't have enough memory, the simulations will run poorly and stakeholders will think that is how the application will run.
"People think they're looking at live data," she said. "It's hard to convince them that it's just a simulation."
And while iRise solves the problem of validating requirements, it is a difficult tool to use, Preston acknowledged. You need to use it often in order to truly understand how to use it.
"It isn't something you can use every six months. We use it a lot. We started with one super user, and now we have three," she said.
If you need support or want functionality not included in the basic features, you can pay iRise to provide consulting.
An iterative approach
When it comes to estimating project completion dates, be sure to allow time for adjustments. When people see a simulation, they will want to make changes -- it's just their nature.
"If you show simulations to people, they will have comments," Preston said. "You can get a lot of answers while doing simulations, and those can help with your documentation."
Analysts adjust the simulations until the stakeholders are satisfied. However, sometimes not all of the functionality can be included in the initial release.
"The biggest problem the tool solves is validation," Preston said. "We do an iterative approach. We ask, 'Can you get by with this functionality for now and then we can add on this and this later?' "
Stakeholders have been open to that type of approach, she added.
The continued growth of the ClinicStation EMR system and evolving healthcare regulations mean the EMR team of 16 business analysts, six project managers, and 30 developers has its work cut out for it.
"We will be working on this system for a long time," Preston said. "We're probably only really now coming in our own to use iRise and find ways to use it. And that's because of our state of being as a team. We were green, we switched platforms -- from VB to .NET -- and made lots of new hires. I think the worst days are behind us."
Dig Deeper on Software Requirements Tools