The first step in defining a PP or ST is identify the
“security environment”.
This means that you have to consider the physical environment
(can attackers access the computer hardware?),
the assets requiring protection (files, databases, authorization
credentials, and so on),
and the purpose of the TOE (what kind of product is it? what is
the intended use?).

In developing a PP or ST, you'd end up with a statement of
assumptions (who is trusted? is the network or platform benign?),
threats (that the system or its environment must counter),
and organizational security policies (that the system or its environment
must meet).
A threat is characterized in terms of a threat agent
(who might perform the attack?), a presumed attack method,
any vulnerabilities that are the basis for the attack, and what asset
is under attack.

You'd then define a set of security objectives for the system
and environment, and show that those objectives counter the threats
and satisfy the policies.
Even if you aren’t creating a PP or ST, thinking about your assumptions,
threats, and possible policies can help you avoid foolish decisions.
For example, if the computer network you’re using can be sniffed
(e.g., the Internet), then unencrypted passwords are a foolish idea
in most circumstances.

For the CC, you'd then identify the functional and assurance requirements
that would be met by the TOE, and which ones would be met by the environment,
to meet those security objectives.
These requirements would be selected from the “chinese menu” of the CC’s
possible requirements, and the next sections will briefly describe
the major classes of requirements.
In the CC, requirements are grouped into classes, which are subdivided into
families, which are further subdivided into components; the details of all this
are in the CC itself if you need to know about this.
A good diagram showing how this works is in the CC part 1, figure 4.5,
which I cannot reproduce here.

Again, if you’re not intending for your product to undergo a CC evaluation,
it’s still good to briefly determine this kind of information and informally
write include that information
in your documentation (e.g., the man page or whatever your documentation is).