Use cases serve their purpose well when their syntax describes the “required” functionality from the system in response to the user interaction, without getting into the details of “how” to execute this functionality. In other words, the system is a black box from the use case perspective.

Using the above style, every use case line that states “system does …< something>”, is a function that the system is expected to perform and therefore can be a potential Functional Specification.

In the famous ATM example, the use case considers the system that operates the ATM machine as a black box. A typical scenario would be:
1- User inserts the ATM card
2- System validates the inserted card is valid to execute financial transactions on this ATM machine
3- System prompts the user to enter PIN number
4- User enters PIN number
5- System validates the PIN number
..
..

In the above example, steps 2, 3 and 5 represents a functionality that the use case author is requesting the system to perform. Or, in the “formal” functional specifications syntax, steps 2, 3 and 5 are translated to:

The system shall validate the inserted card is valid for financial transactions on this ATM machine
The System shall prompt the user to enter PIN number
The System shall validate the PIN number entered by the user

However, there may be cases where a use case line will not qualify to be a Functional Specification, although it starts with “System does something…”.

Can you come up with any examples?

n his book (Aspects oriented software development) Ivar Jabcoson has distinguish between two major categories of use cases: application and infrastructure use cases. Application use cases describe how users interact with the system to perform the desired functionality(to capture functional requirments). Infrastructure use cases describe what the system does to add qualities such as usability, reliability, performance, and supportability to each step of an application use case(non fncational requirements).

Use Cases/Functional requirement define the behaviour of the system. The behaviour is identified by the verbs of the system. For example, placing an order, modifying or deleting an order are essentially the behaviour of the system and the corresponding verbs are add, modify, delete.

I'm a systems analyst with a couple of questions:
I work in a small team of business analysts, systems analyst & developers, so the idea of having the BA document the functional requirements in the use case effectively could save a lot of time if the developer can read this directly. Practically, is it true that the functional requirements do not need to be re-dcoumented in a separate format for the developer?

Traceability - how do you handle this? Is the Use Case scenario traced back to each business requirement? Then the technical specification traced back to the use case (in lieu of functional requirement)?

Readibility - can/should developers be adept at reading use cases? Seems easy enough to me.