Unfortunately, there is no cut-and-dried way to identify functional dependencies.
One will have to rely on the knowledge you gain during requirements analysis ^[1] to make those determinations. You may design a database for an unfamiliar company, or need to account for data on subjects about which you have little prior knowledge. The interviews you conduct and the outside reading you do are absolutely invaluable in identifying the business objects to be represented in the database and the functional dependencies in the resulting relations.

One strategy you can use to determine whether a field is functionally dependent on the entire primary key is to ask if the field is an attribute of the business object represented by the table or if it is a foreign key field used to establish a link with another table. If neither is true, there is a good possibility the field is not functionally dependent and, therefore, the table is not in 2NF.

In relational notation, a functional dependency is represented with the -> symbol. For example:

CustID -> CustFirst, CustLast, Address, Phone

The -> (arrow) character is read as "determines,” so the functional dependency above is read as "CustID determines CustFirst, CustLast, Address, and Phone."
If a functional dependency has a multi-field determinant^[2], separate the fields to the left of the arrow by a comma. An automobile insurance policy, where each policy could cover more than one car under different terms, is an example of a multi-field determinant:

PolicyNo, CarID -> Deductible, CoveragePlan

A functional dependency is a one-way relationship between two attributes such that at any given time, for each unique value of attribute A, only one value of attribute B is associated with it through the relation. For example, assume that A is the customer number from the orders relation. Each customer number is associated with one customer first name, one last name, one street address, one city, one state, one zip code, and one phone number. Although the values for those attributes may change, at any moment, there is only one.

Before you move on to the next lesson, complete the following exercise to reinforce your understanding of functional dependencies.
Functional Dependencies - Exercise

[1]Requirements analysis: The stage in the database design cycle when designers find out everything they can about the data the client needs to store in the database and the conditions under which that data needs to be accessed.

[2]multi-field determinant: A determinant consisting of more than one field.
The next lesson reviews the procedure for putting a relation in 2NF.