Changes between Version 7 and Version 8 of BluePrint/CAPMobileApp

01/17/16 21:49:45 (8 years ago)
Lutz Frommberger

Introduction and User Story


  • BluePrint/CAPMobileApp

    v7 v8  
    44== Introduction ==
    5 <Briefly describe the solution?>
    6 <What problem is this solution solving?>
    7 <How will this solution add value to Sahana?>
    8 <Name any similar existing solutions>
     5The app is supposed to be a mobile app to issue alerts for several hazards to be included into SAMBRO/Sahana.
     7The app will complement the web based GUIs for issuing alerts to enable a mobile solution even working in
     8areas with weak internet connectivity.
     10An existing similar solution is [ mobile4D], a bi-directional hazard reporting and alerting tool developed at
     11the Capacity Lab at the University of Bremen.
     15<Briefly describe the solution?>[[BR]]
     16<What problem is this solution solving?>[[BR]]
     17<How will this solution add value to Sahana?>[[BR]]
     18<Name any similar existing solutions>[[BR]]
    1021== Stakeholders ==
    11 <Who will be the users of the solution?>
    12 <Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?>
    13 <How will stakeholders be affected?>
     22<Who will be the users of the solution?>[[BR]]
     23<Who else will be affected by this solution? eg. Developers, Users of Existing Functionality that may be changed?>[[BR]]
     24<How will stakeholders be affected?>[[BR]]
    1425Tip: Engage these stakeholders in the development of your !BluePrint.
    1627== User Stories ==
     28An authorized user finds himself in a situation where he/she is in the need to issue an alert, but does not have access to a computer or/and a sufficiently stable internet connection. The user can now use the app and fill in the data via a structured interface. After confirming the data, the app takes over and sends the data to the Sahana server as soon as internet connection is available again without the user having to take care of it. (Alternatively, the app uses SMS to send the data. This is transparent to the user.)
    1832<A good User Story should answer the following questions:>
    2135<* Why they want it to do that? (goal)>
    2236<eg. A <type of user> wants the solution to <do something for them> so that <can achieve a goal>.>
    2439== Requirements ==