View source for Talk:Apps/WebRTJunePRD

== Questions and Comments ==

"This document covers the product requirements for the Android WebRT, code name "Soup", for the June, 2012 milestone."

(jsmith) Curious, why is June 2012 picked as the date for the next major milestone? Is there a major conference? Time to market?

(jsmith) What level of quality is this next milestone? Beta-level quality?

"Tier 1 App Support"

(jsmith) Could you define what you mean by "support?" Does this mean that Soup needs to be able to run the app with its major points of functionality with no issues? In other words, could you be more specific about the quality requirements?

"Improve User Experience Issues"

(jsmith) Could you identify specific pain points in our user experience currently that we want to aim for?

"Publish "Mozilla Marketplace" in Android Market"

(jsmith) Will this be a beta or GA?

Open Issues/Risks

(jsmith) Might want to add "tracking and ensuring fixes of evangelism issues," specifically in regards to top apps (tier 1s especially).

(jsmith) What about estimates? For example, how is estimated effort being taken into account? What measurements and metrics are being used?

User Scenario/Stories

(jsmith) Suggestion - In wording user stories, instead of using "Alice" as a default name to a user, point out the stakeholders interested, define personas that represent a specific user type (One user type could use the name of "Alice"), or define user classes. Here's an example:

User story originally written up:

"Alice can use and app that plays music"

User class information example:

Alice: Avid smartphone user, uses as a primary way to listen to music, searches for music on this device, etc.

Altered user story:

"As an avid music listener on my smart phone, I want to be able to play music on apps on Soup to be able listen to music on the go."

General template for user stories I've used before:

As a <type of user>, I want <some goal> so that <some reason>.

Prioritized Requirements

(jsmith) Could you include discussion of quality requirements? For example, what about security? Resilence? Availability? Performance? UX?

(jsmith) What about requirements more involving the apps experience (actually using the app)? Experimenting with top apps could provide some insight into this (noting this cause I've seen many bugs in this area in prepping for MWC).

(jsmith) Could you be more detailed in your requirements breaking down some of the fine-grained details? Use case descriptions could help detail this more to analyze steps, exceptional cases, special requirements, preconditions, postconditions, etc.

Metrics

(jsmith) Could you post this information on the Apps Dashboard wiki on the intranet (and include the information there)? This would be useful for pushing forward with the dashboard.