Resources

Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Resources

Page tree
Skip to end of metadata
Go to start of metadata

How to Join

 

Audio, Chat, & Screen Sharing (latest Firefox, Chrome, or other WebRTC-compatible browser)

Audio Only (Telephone or your favorite VoIP client)

Be Prepared for Your Meeting

 

Agenda

  • Impromptu topic: How should we capture requirements?
  • Review next meeting agenda

Notes


Attendees
  • Darius
  • Wyclif
  • Terry
Agenda
  • None
  • Impromptu topic: how should we capture requirements?
Notes
  • Talked about past processes for capturing requirements:
  • baseline behavior is what you see in a typical "Active Projects" or "Assigned Projects" page
  • with past BA support from TW, IU, and Merck we tried more formal processes, but these never stuck after the BA moved on
  • Wyclif: one big problem was that implementers never actualy got involved and joined in calls
  • Terry: it sounds like a problem that developers are generating requirements
  • Darius: yes, they often do what would be a BA role
  • Regularly-scheduled calls have not worked with implementers. Specifically-advertised calls have occasionally worked, but not 100%
  • Terry: Sometimes SMEs may not be the implementers
  • Terry's proposal:
  • Small group (including dev, SME, implementer) get together for ~3 rounds of requirements gathering
  • => produce a proposed Requirements Document, which is then reviewed by a bigger group
  • Allergies project was very successful for requirements gather (but unsuccessful from the perspective of Jonathan, since it took 4 months before it was even worked on)
  • Daniel: lack of Product Owners for features has been for lack of such a person (not for lack of wanting one)
  • Malnutrition/ Undernutrition as a use case for requirements gathering
  • develop process that is repeatable for requirements process
  • constrain the 'requirements' domain - which part of nutrition do you address
  • initial requirement/ design document
  • assume ongoing iterative development for requirements as well as input from development team 
  • identify who is interested/ what work has already been done in this area ( e.g. MSF requirements tthat can be shared)
  • use previous requirement development as a starting point for review 
  • active implementation that is interested in this domain ( e..g PIH in this area)
  • identify appropriate SMEs/point of care users/implementers/ development support( from tech community)
  • schedule calls to discuss/ inform the requirements , including technical possibilities 
  • aritfacts have been the tickets that have been generated
  • design philosophy document
  • break down into sprints of work stories and issues that were developed for the requirements phase
  • use cases that were developed and then generate the requirement document/ public facing design document 
  • not just tickets to get development done, but there is a design document/ requirements document 
  • Darius: just do it. You don't need to ask for anyone's permission to (a) try out a better design process and template, (b) respond to a request from an active implementation to have OpenMRS help centrally design some feature
Allergy example:

Transcripts

  • Audio recording of the call: Listen online or download (available after the meeting)

Feedback on this page? Questions?

Visit OpenMRS Talk, our community discussion hub.

Copyright © 2004-2016 OpenMRS Inc. By using this site, you agree to the OpenMRS Privacy Policy.
Text is available under the Creative Commons 4.0 International Attribution License (CC BY 4.0).
Software is available under the Mozilla Public License 2.0 with Healthcare Disclaimer (MPL 2.0 HD).
"OpenMRS" is a registered trademark and the OpenMRS graphic logo is a trademark of OpenMRS Inc.