No announcement yet.

Use Case Discussions

  • Filter
  • Time
  • Show
Clear All
new posts

  • Use Case Discussions

    Back again...

    From the IVI mailing list comes this *request*

    If the community has applications and use cases for IVI and needs support
    for it from MeeGo IVI's software stack then this is valuable input. I would
    start with a high-level top-down user-centric approach asking questions:
    What do drivers expect from their IVI system? What do passengers expect from
    it? What would kids/teenagers/adults in the rear seat be looking for? MeeGo
    IVI will not necessarily solving all it but if you then decompose it to the
    level of what data, functionality, connectivity, etc. does the IVI stack
    need to provide to support these use cases you will get a list of features
    that can be implemented in MeeGo IVI.
    So I thought I would throw this out there for forum feedback... I've included some
    sections of a typical Use Case from Wikipedia to help with their creation.

    BTW: this maybe useful to anyone working on a frontend

    Use case name

    Without a goal a use case is useless. There is no need for a use case when there is no need for any actor to achieve a goal. A goal briefly describes what the user intends to achieve with this use case.

    A summary section is used to capture the essence of a use case before the main body is complete. It provides a quick overview, which is intended to save the reader from having to read the full contents of a use case to understand what the use case is about. Ideally, a summary is just a few sentences or a paragraph in length and includes the goal and principal actor.

    An actor is someone or something outside the system that either acts on the system a primary actor or is acted on by the system a secondary actor. An actor may be a person, a device, another system or sub-system, or time. Actors represent the different roles that something outside has in its relationship with the system whose functional requirements are being specified. An individual in the real world can be represented by several actors if the individual plays several different roles and has multiple goals in regards to a system. These actors interact with the system and do some action on it.

    A stakeholder is an individual or department that is affected by the outcome of the use case.[4] Individuals are usually agents of the organization or department for which the use case is being created. A stakeholder might be called on to provide input, feedback, or authorization for the use case.[5] The stakeholder section of the use case can include a brief description of which of these functions the stakeholder is assigned to fulfill.

    A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case. That is, if the system is not in the state described in the preconditions, the behavior of the use case is indeterminate. Note that the preconditions are not the same thing as the "trigger" (see below): the mere fact that the preconditions are met does NOT initiate the use case.

    A 'triggers' section describes the event that causes the use case to be initiated. This event can be external, temporal or internal. If the trigger is not a simple true "event" (e.g., the customer presses a button), but instead "when a set of conditions are met", there will need to be a triggering process that continually (or periodically) runs to test whether the "trigger conditions" are met: the "triggering event" is a signal from the trigger process that the conditions are now met.

  • #2
    Use Case Name: Adjust Volume (Driver)

    Goal: Change volume of audio to an acceptable level for Driver

    Summary: Driver needs to adjust volume of audio.

    Actors: Driver

    Stakeholders: Passengers

    Preconditions: Working audio, sound being produced



    • #3
      Audio Use case discussion here: