/
2016-01-04 Design Forum

2016-01-04 Design Forum

Jan 06, 2016

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:

    Wiki page: https://openmrs.atlassian.net/wiki/x/ceBTAQ

    Example tickets: https://issues.openmrs.org/browse/RA-299, https://issues.openmrs.org/browse/RA-345

Transcripts

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