2016-01-04 Design Forum
Owned by Jamie Thomas
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)
- Toll-free (United States): +1 (888) 510-4073
- International: +1 (201) 479-2055
- View a list of local access phone numbers for various countries. After dialing, when prompted enter meeting number 888-510-4073.
Be Prepared for Your Meeting
- Consider connecting via telephone/VoIP for best audio quality.
- If connecting via computer, be sure your network has the audio/video bandwidth you need.
- Before attending or presenting via computer, try the web browser microphone/speaker test.
- Read the UberConference support pages for troubleshooting or contact them in case of problems.
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
Transcripts
- Audio recording of the call: Listen online or download (available after the meeting)