Use-Case Modelling is the standard Requirements elicitation method for many projects.

Use
cases, like storyboards, identify the who, what, and how of system behaviour. Use cases describe
the interactions between a user and a system, focusing on what the system does for the user. The
use case model describes the totality of the system's functional behaviour.

Applicability: Use Cases have proven particularly valuable to specify all kind of (even complex)
functional requirements in structured and manageable way.

Advantages:

Use Cases improve the communication between the development teams and the stakeholders in
their ability to help teams to understand the value the system must provide for its
stakeholders. Use Cases also make the elicitation of the requirements more precise.

Use Case writing Template with explanations of the attributes

A use-case must encapsulate the complete flow for one logical transaction or set of related
transactions for an actor. However, an interesting debate arises when you have to decide whether
a particular flow must be part of an alternative flow in an existing use-case, or it must be spun off
into a new use-case altogether. I would go by the rule that as long as the alternative flow does not
deviate from the basic purpose of the use-case, it must remain as an alternative flow.

For further clarifications please find enclosed a use-case from Payments. Have a look at the
alternative flows. Most of them could actually have been separate use-cases.

Identification of Use Cases:

Can be screen based
Menu link based
Functionality /Sub functionality based

Structuring Of Use Cases:

Ask for the project concept document
Go through the existing application if it is an enhancement project.
Decide on the number of the use cases
Basic use cases included and extended use cases etc...

Requirements approach and solution approach

Get your basics in visio, or MS paint .These really help in impressing the client.
Coming up with suggestions .
Open issues should be accompanied by suggestions . Instead of being open convert them
into leading let the client choose the options.
This makes the process faster and the client have a good impression on your quality input
.Because everybody likes new ideas in the requirements gathering phase.
Fix the point of contacts that can provide you requirements
Dont accept requirements from anybody and everybody.
To avoid confusion devise a clear communication channel.
Store all the mails for requirements because the business has tendency to deny many things
afterwards.
No verbal requirements either in mails or in hard copies
Store all these.
Whenever in confusion talk to the people in development team.
Follow the rules of consistency for fonts; font sizes etc. as per the clients organizational templates
Understand the overall frame work .meaning which is possible/allowed or not
In some cases use of java applets are a not allowed. But if u suggest, it will be well received but
not accepted /implemented.

Most important:
Do your home work on the domain front. Understand the generic processes and the recent
market developments in the area. This helps realistically. Many a time this will help you to
confuse the client if not convince

Attribute Description

Name of Use Case Each Use Case must bear a meaningful and short name. The
name should express what happens when the Use Case is
performed. Formulate it in an active voice; e.g. enter retail
customers, view account info

Identifier of Use Case
Each Use Case must bear a short unique identifier (primary key).
This helps to identify a Use Case efficiently. Consider that an
identifier must not be changed during the life cycle of a Use Case
(otherwise the references made would be lost).
One construct can be UC 02 02 is the number
Included use cases can be UC 0201

Type of Use Case There exist three important types of Use Cases: (1) Base Use
Case, (2) Included Use Case, (3) Extending Use Case.
(Details can be found in the Use Case Guidelines)

Short description / goal of the
Use Case
Each Use Case is to be described briefly by one to three
sentences. The description should reveal the purpose and goal of
the Use Case. It is central that the description is easily
understandable. Outsiders should be able to understand what the
Use Case is going to do.
No referencing to any item in the Use case
No details

Actor(s) A list of actors that are involved in the Use Case must be
described. Actors may be users or IT components. Actors may
initiate Use Cases or they may receive the result of a Use Case.

Pre-conditions Pre-conditions of a Use Case define conditions that must be true

when the Use Case is invoked.
The parameters can be regarding
System/data base availability
Logged in User
Appropriate contracts and access rights
Examples of pre-conditions: (a) The database contains at least one
data item that can be selected; (b) Sunday evening 11pm (potential
meaning: the scheduler invokes the Use Case every Sunday at
11pm)

Basic flow Describes the interactions between actor and system that are
needed in order to meet the goal (e.g. the post conditions) of the
Use Case. The steps are described in sequential order. This
represents the basic flow; sometimes called happy flow.
A step has the following format: <Step no><Description of
interaction>. The inclusion of a sub Use Case in a certain step can
be expressed through the keyword INCLUDE.
The
No of columns displayed
Name of the columns displayed
Sequence of columns
Lay out static or dynamic
Collapsing/expanding function in the rows
Any input filed to be activated by selection of other input
parameter
Any Use case (Include or extend..) that could be invoked
from this particular screen/use case.
Alternative flow 1
Alternative flow 2
Alternative flow n
Post-conditions
Extension points
Use Case-specific
non-functional requirements
Special considerations
Creation date
Variations of the step ordering (use case flow) are described as
alternative flows. Each alternative flow is described in a separate
row.
Example:
Alternative Flow: Pin is wrong
Location: Basic Flow, step 2
Condition: Client enters the wrong PIN three times
Actions: 1. EC card will be collected
2. A message appears on the screen.
Continue: Use Case ends.
A more generic e.g. could be the flow on click of Save. Also any
generic error handling in case of an error in the normal execution of
use case.
Alternative Flow: Selected amount is too large
Location: Basic Flow, step 4
Condition: client selects an amount larger than CHF 700
Actions: 1. Message "amount too large" appears
Continue: Basic Flow, step 3
Clicking Cancel..
Post-conditions of a Use Case define conditions that will be true
when the Use Case is completed successfully. Post-conditions
provide valuable information to be used for testing an application.
Example: the orders have been transmitted successfully to the
system 4711.
Any hyperlinking (this can be moved to the Post-conditions
saying the user can navigate to blah blah blah)
An Extension Point is a feature of a Use Case that identifies a point
where the behavior of a Use Case can be augmented with
elements of another (extending) Use Case.
Example: If amount to be transferred is larger than CHF 500 Mio.,
extending Use Case xyz is invoked.
Are there any non-functional requirements that apply for this
particular Use Case? If so, they must be listed here. The format to
be used is: <keyword><description of requirement>.
Some keywords are: response time, timeliness of data, throughput,
usability, availability.
Non-functional requirements that apply for more than one Use
Case must be placed in the section Specification of non-functional
requirements.
Some Use Cases require particular data sources, interfaces,
algorithms and the like. Such elements may be specified here or in
another section of the requirements specification.
Example 1: For processing step 2 of basic flow, data of table xxxx
have to be used. Example 2: Data needed in Step 3 have to be
collected via interface kkkkkkkk'. Example 3: To perform step 4,
algorithm bbbbbbbbbbbbbb has to be used.
When and by whom the Use Case was initially created suggest
using document history instead of having this section.
 Modification When and by whom the Use Case was modified. As above.

Table 1: Annotated Use Case template

Action:

Sort function
Filter function
Controlling buttons
Buttons which invoke other use cases
Buttons which opens gate to interfaces

Input table:

Drop down:

How the values are populated? As in if they are to be populated from the backend, or hard coded
Hardcoded if yes, then suggest to mention the values in the UC.
User profile dependent?
Instrument dependent or on any other factor that may be UC specific.
Do the values get affected by any changes to any other dropdowns/inputs?
What is the default value? Are there multiple default values as per the client contract? (Multiple
default values for a drop down are not possible. Although it could be a case wherein each user
may see a different default value if the system is so designed.)
Inheritance allowed??
Formats of the fields
A brief description as to what the field caters to may be worth capturing.

Text box:
What would be the valid values? Is an error message to be displayed to the user in case invalid
data is entered?

OUTPUT Table

Format of out puts (in diff languages)

Source of delivery?

MATRIX

Important thing is matrix to gain clarity .Matrices is advised to be used for following
circumstances.
But the matrix should be displayed in the UC only.
Inheritance across screens and parameters
Product = fields appear for instrument /transaction / reporting details
Column sequence
Different stages of one particular transaction/ operation and what all the user can perform on that.

MUST HAVES
Not only formatting related but also other Business rules and GUI specs.