Why don’t computer systems help me as much as I think they should?

Why don’t computer systems help me as much as I think they should?

Answer: We don’t really understand the requirements of the process.

Chapter 2 of 3. Need to catch up? Read the previous post in this series about scientific workflows.

My wife and I recently ordered an iMac. It was our first Mac, and on the day that it arrived, I anticipated a frustrating evening trying to set the machine up and get it to work. Instead, my wife had it fully operational before I got home. As she put it, “Everything just made sense.”

I am sure this sentiment is nothing new to Apple aficionados. But have you considered just how much work went into making the iMac interface intuitive? Really smart people worked a really long time to understand how the hardware, the software, and the user could work most naturally together. These smart people then translated their knowledge into clear instructions for how the interface should work. These instructions—called requirements in the business world—and the metadata that communicated the requirements to the programmers and designers are the reason that the iMac is intuitive. There were unlimited opportunities for the iMac interface to cause confusion for the user (and perhaps induce some bad language). Instead, well researched, clearly written, and precise requirements for the interface made the iMac so easy to use that the interface itself is almost invisible.

Complete and clear requirements are also a critical element in the successful design and execution of workflows for pharmacometric analyses. Developing requirements and formally writing them down is the responsibility of the scientist in charge. But, in fact, many scientists don’t know how to write requirements. They won’t delegate a task like dataset creation because they don’t know how to tell programmers what they need. As it turns out, writing requirements for programmers is only one step in the path to automation. Machines are not nearly as versatile as a good programmer in inferring intent, so the requirements must be even more rigorous and complete.

In order to think more clearly about requirements, let’s look at some tasks in a workflow for a model-based analysis. First, consider the critical relationship between the design of an experiment and the presentation of results. The scientist must design the experiment so that it yields valid results that fill the identified gap in knowledge. Those results must then be presented in a clear and informative way to facilitate understanding and interpretation. Scientists understandably take great pride in their skills at these tasks.

But now let’s consider what other tasks must be completed between these two bookends of a pharmacometric workflow. Data is collected, processed, and archived. Analysis-ready datasets are created and an exploratory analysis is performed. A base model is developed, covariates are tested, and a final model is validated. Other subtasks may be required; such as, generating goodness-of-fit plots, creating tables and figures, or computing transformations of primary parameter estimates. [Check out Informatics: The Fuel For Pharmacometric Analysis if you want more detail.]

The successful completion of each of these tasks is linked to dataset structure and content and to the analysis method, all of which relate to the underlying requirements of the experiment and the presentation of results. A mismatch at any point can require frustrating efforts to recreate the dataset, reprogram the graphs, or repeat the analysis so that the results meet the original intent.

Taking this a step further, without adequate requirements, any attempt at process automation will only partially succeed. Time-consuming and expensive work-arounds will be needed to extract the desired results.

Writing requirements is a skill that must be learned and a process that must be respected, because the time spent defining and refining requirements is more than recovered by avoiding work-arounds and re-do’s. Gains in efficiency and productivity result from well researched, clearly written, and precise requirements.

Are you hooked? Don’t worry, there’s more where that came from. Read the next installment in this series about scientific workflows Innovation at the Intersection of Creativity and Automation. Also visit my LinkedIn profile where I will post a question for discussion and an invitation to you to share your experiences.

Grasela TH, Fiedler-Kelly J, Cirincione B, Hitchcock D, Reitz K, Sardella S, Smith B. Informatics: the fuel for pharmacometric analysis. AAPS J 2007:9(1):E84-E91. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2751306/pdf/12248_2008_Article_9184.pdf. Accessed April 27, 2011.