2016-01-04 Design Forum

Owned by Jamie Thomas
Last updated: Jan 06, 2016
2 min read

How to Join

 Click here to expand...

 

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)