shann

• Sep 25th, 2006

 

use cases are simple and powerful way of expressing a functional requirement , or behaviour of a system. use case are primarily a way to express a systems requirements,principally its behavioral ones.

Nik_Agarwal

 Profile Answers by Nik_Agarwal Questions by Nik_Agarwal

• Sep 25th, 2006

 

Use cases are created by Business Analyst, these helps better undertand the specification/requirements of the application. Test cases are written on the basis of Test Scenarios and, Test Scenarios are written on the basis of Use cases.

mahi

• Sep 26th, 2006

 

Usecase describes the sequence of actions that a system perform to validate functional requirements.

Usecase ID,Usecase Name,Summary, Priority, Preconditions , Postconditions , Flow events

Narsimha rao

• Sep 27th, 2006

 

template is form he collect that form and go to client , take all detail from client, when it's become document .

Susanta Behera

• Sep 30th, 2006

 

Use cases are described the functionalities in terms of I/p .action and O/p and it is created by Business Analyst

S.Kumar

• Oct 10th, 2006

 

Use Case:

Use case is prepared by Business Analyst in the Functional Requirements Specification (FRS) whish is nothing but a steps are given by the customer. Designed before the Project started.

chandu

• Nov 16th, 2006

 

use case defines a graphical notation for use cases, but it refrains from defining any written format for describing use cases in detail. Many people suffer under the misapprehension that a use case is its graphical notation (or is its description). While the graphical notation and descriptions are important, they are documentation of the use case -- a purpose that the actor can use the system for.

The true value of a use case lies in two areas:

• First, the written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems.

• Second, the position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team.

It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics include performance, scale/management issues, or standards compliance.

The diagram on the right describes the functionality of a simplistic Restaurant System. Use cases are represented by ovals and the Actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Prepare Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case. However, note that actors are a form of role, a given human user or other external entity may play several roles. Thus the Chef and the Cashier may actually be the same person.

Three major relationships among use cases are supported by UML. The UML standard describes graphical notation for these relationships. In one form of interaction, a given use case may include another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from several use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label ?include?. This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values.

CHANDU

• Nov 17th, 2006

 

use case defines a graphical notation for use cases, but it refrains from defining any written format for describing use cases in detail. Many people suffer under the misapprehension that a use case is its graphical notation (or is its description). While the graphical notation and descriptions are important, they are documentation of the use case -- a purpose that the actor can use the system for. The true value of a use case lies in two areas: First, the written description of system behavior regarding a business task or requirement. This description focuses on the value provided by the system to external entities such as human users or other systems. Second, the position or context of the use case among other use cases. As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of system behavior, a common understanding between the customer/owner/user and the development team. It is common practice to create supplementary specifications to capture requirement details that lie outside the scope of use case descriptions. Examples of these topics include performance, scale/management issues, or standards compliance. The diagram on the right describes the functionality of a simplistic Restaurant System. Use cases are represented by ovals and the Actors are represented by stick figures. The Patron actor can Eat Food, Pay for Food, or Drink Wine. Only the Chef actor can Prepare Food. Note that both the Patron and the Cashier are involved in the Pay for Food use case. The box defines the boundaries of the Restaurant System, i.e., the use cases shown are part of the system being modelled, the actors are not. Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case. However, note that actors are a form of role, a given human user or other external entity may play several roles. Thus the Chef and the Cashier may actually be the same person. Three major relationships among use cases are supported by UML. The UML standard describes graphical notation for these relationships. In one form of interaction, a given use case may include another. The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from several use cases into a single description. The notation is a dashed arrow from the including to the included use case, with the label ?include?. This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior. There are no parameters or return values. Email:sekhar727@gmail.com 9985532798

Dharmakrishnan

• Dec 12th, 2006

 

Hi

 

Use case it a simple way to express the functional expression. Use case  are  prepared by the business analyst .Based  on the  use case  the  test case are  written The  following  are the item  which  appear in the  use case

 

• Use case id
• Use case name
• Summary
• Priority
• Pre condition
• Post condition
• Flow event