TIL (today I learned)... the importance of requirements writing

Informatics is very much a business. Like most businesses, you provide a service. Whether it is to implement, develop, support, or train, it is necessary to consult with end users. In clinical informatics, the end users are physicians, nurses, and pharmacists.

When a user requests a function be built or a feature implemented, they often do not think like an IT person. Because of this, their expectations may or may not be realistic. What may seem logical to a clinician may not be pragmatic from a programmer's perspective. People in healthcare also tend to be perfectionists; they will always demand the project be revised an infinite amount of times in order to achieve perfection. Essentially, you end up with the Pareto principle (also known as the 80-20 rule); 20% of your user base will take up 80% of your time. The key to solving this is to set expectations and service agreements up front using requirements writing.

Requirements writing is is a process familiar to many business analysts and software engineers. It is an investment before undertaking a project which saves time, money, and effort. First, you must clearly identify the underlying problem that needs to be solved. Next, determine if the problem necessitates a technological solution. Many problems or issues are related to a human process; adding technology only makes the problem faster and overspec'ed (sp?).

Once the problem is identified, research should be completed on which real world "best practices" may mitigate it. Finally a requirements document is written. Simply put, requirements are statements of what a system should do rather than how it should do it. Requirements come from the end users (clients) and are narrated specifically as to what they want a feature to accomplish.

• What does the user need?
• What does the system have to do to satisfy that need?
• Do any components need to be built? If so, what does it do and how does it interact?

A good requirements document keeps a project on schedule and serves as a contract as to what work was agreed upon, how much resources were alotted, and the time table for production. Say Dr. A shows the project to Dr. B and Dr. B has a brilliant idea to improve the project by adding xyz. If xyz wasn't in the original requirements document, he is out of luck. That's why there's this thing called "version 2.0", which, you guessed it, will require them to start over with a new requirements document.

Currently, I don't think many hospitals take this approach when developing their clinical systems (a quick literary search yielded nothing). Used effectively, it can really help prioritize workload, set realistic expectations, and put a stop to people randomly sticking their head into your office and requesting a feature (a term I heard affectionately called a "drive by").

Ignore this step at your own peril as it may lead to chaos in the project timeline and land you in development purgatory (a similarity pharmacy informatics and web design share).

Reference:

¹ IEEE Recommended Practice for Software Requirements Specifications, Software Engineering Standards Committee of the IEEE Computer Society. Approved 25 June 1998

Posted via email from RxINFORMATICA