Clinical Architect: Requirements Engineering.
NOTE: This post is a follow up from the overall post on what does a clinical architect need to know.
A Clinical Architect should be able to design requirements, even though that might not be a day to day activity.
I prefer terms like requirements design or requirements engineering as I don’t think requirements are just out their to be picked off trees. Requirements elicitation, for example, suggests you just have to ask users. I do not think requirements design consists of pulling some people into a room and asking them what they need. Or at least, I do not think that is the only thing required.
While the user is never wrong, the user is not always right. Especially in a meeting room, away from their daily work when they haven’t been trained to think about requirements. You can often get suggestions for solutions (just trying to be helpful!) and a lack of understanding of the needs.
“I need a soft ware for electronic call schedule management”
“I need secure email”
“I need… version 9 of the EMR Cardiology Suite by MegaCorp”
With these statements, one isn’t sure why they need these solutions – what are the solutions addressing? Was it that that EMR Cardiology Suite was seen at a conference? Or were the reasons for secure email really about an integrated electronic solution for referral management?
Complex problems and their “solutions” are intertwined (see Wicked Problems), but it is important to have the context of the problem somewhat understood before exploring solutions (and then re-describing the problems being addressed).
A Clinical Architect’s role here is two-fold. First, to have an understanding of the process used to engineer requirements and be able to articulate it. Second, to ensure that potential solutions are reviewed in the broader context of the organization: how can the solution be reapplied to other settings? how aligned in the solution to other aspects of care delivery? how much patient information is being locked away in an isolated clinical information system that would be useful to other providers or the patient in other settings? These are the types of broader questions that should be explored with the organization’s clinical architect during project scoping and in the more detailed requirements engineering activities.
Just for reference:
BABOK 2.0 is now available free on Google Books. To be shared with BAs, absolutely, but also adapted to the organization so that there is local expertise in a subset of approaches. (They also speak of requirements elicitation…)
Related posts:
- What does a Clinical Architect Need to Know? I have been asked a question by a colleague at...
- Clinical Architect: General Enterprise Architecture NOTE: This post is a follow up from the overall...
- Clinical Architect and Software Lifecycles and Design Methodologies NOTE: This post is a follow up from the overall...
Related posts brought to you by Yet Another Related Posts Plugin.