For the purposes of defining NATs, each of these IPs must be defined as a /32. If you define them as /28s, then traffic to all 16 IPs in that CIDR range will match the first NAT you have defined in your policy.
EDIT: Expanding on the above; this may vary dependent upon platform, but based on my experience on Checkpoint NAT, consider the following. (I'll write up Cisco as well, at a later stage; takes a bit more effort to express).
For the purposes of this example, Checkpoint NAT rules can be considered in the form:
|| Original || Translated ||
|| Src | Dst | Port || Src | Dst | Port ||
In this case, we are concerned with the 'Original Dst'. Let's assume that we're creating a rule for traffic destined for 203.214.69.1, which will be redirected to an internal web server.
Original
Source: Any
Destination: 203.214.69.1/28
Port: TCP/80. TCP/443
Destination:
Source: Original
Destination: 192.168.1.1/32
Port: Original
The problem with this rule is that 203.214.69.1/28 will match traffic destined to any IP in the range:
[ 203.214.69.0 ... 203.214.69.15 ]
And any subsequent rules (for example, redirecting SMTP traffic to 203.214.69.2 to internal server 192.168.1.2) will never be hit.
The cases where this prefix will need to be defined as a /28 are:
When being used for routing. It sounds like you only have one ISP, so I would expect that you will have a static default route pointing to your ISP's default gateway, and your ISP will have a static route for your allocated /28 pointing to your internet facing device (firewall?). In this case, traffic for all these IPs will be routed to your internet gateway regardless of how you define the addresses in your firewall policy.
When you are using it as a true layer 3 subnet, where all hosts need to be in the same broadcast domain. As you have said these addresses will be used to NAT to internal webservers, this case also doesn't apply.