Is this table really in first normal form (1NF)?
If all the attributes/columns of that relation/table always contain atomic values (i.e., they accept exactly one value —neither no value, nor two or more, nor NULL marks— of the corresponding simple domain1, 2 per tuple/row), then yes, that relation/table meets first normal form (1NF); otherwise, no, it is not in 1NF, it is unnormalized. 

Naturally, I do not know the informational characteristics of the business environment of relevance (e.g., what meaning is ascribed to each attribute/column by the end users and business experts, how each attribute/column is associated with the others, etc.), so who knows. 

The question so far lacks any sample values (paramount factor to determine the respective domains), lacks any description about the business scenario at hand, lacks details about how the data points of significance are associated with each other, etc. (yes, the attributes/columns are represented by certain words, but the same word may carry different meanings in different contexts, thus an unrelated reader cannot know with exactitude what their connotations are in the scenario under consideration); therefore, as the post stands, it is impossible to evaluate properly the relation/table included in it.

The fact that the question does not contain that kind of necessary information is understandable if you are starting to learn about normalization according to the relational paradigm, but be aware that making guesses when laying out a database is counterproductive. In this regard, it is worth to point out that working closely with the business experts is indispensable in any professional database design project (including normalization at the logical layer, of course). 

In case you are involved in a training/school course, I would highly recommend that you request an appropriate contextualization of the exercises from your teacher. If, on the contrary, you are learning on your own, you should look for sound materials in the relational field to optimize your efforts (this advice is more fitting now that you have clarified via comments that you are learning by yourself). 

In agreement with the deliberations above, it is opportune to remark that relational database design is a craft that demands high precision.



1 Basically speaking, a domain is a set of values of the same type. N constraints can be attached to a domain. N relations/tables of a database can have n attributes/columns which draw their values from the same domain. An attribute/column can have, in turn, specific constraints only applicable to itself.

2 A domain is simple if (a) it is not comprised of relations/tables and (b) its values cannot be decomposed by the database management system. Avoiding non-simple domains when delineating a database is useful so as to take full advantage of the declarative power of a data sublanguage, which in practice facilitates the implementation of constraints and manipulation operations.