From the IVI mailing list comes this *request*
So I thought I would throw this out there for forum feedback... I've included someQuote:
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.
sections of a typical Use Case from Wikipedia to help with their creation.
BTW: this maybe useful to anyone working on a frontend :eek:
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. 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. 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.