Don't Pollute Your Domains

Good software tries to model and implement the various needs of a system or application apart from each other.  This is called "separation of concerns".  A concern can be many things, but in general, it is a concept.  In AOP, Aspect Oriented Programming, there is an ability to actually code a concern that crosscuts many locations in an application as a single entity.
This capability allows a developer to write code that does not have duplication (DRY, don't repeat yourself).  It is likely that requirements for your system are written by a business analyst, not a computer scientist.  This means the person may likely know many things from software development such as terminology from security.  The gravity of an agile world encourages us to "keep it simple".  This means a requirement will be written in an allegedly simple way, incorporating security features into a business operating feature.  This attempt at simplifying things by uniting security concepts with application concepts, leads to "domain pollution".  That is the domain of the business is all that the SME (Subject Matter Expert) writes.  Well, this leads to domains that are abominations.  Animals aren't just created by declaring this dear needs to have wings because it may run out of food sources, so we need it to be able to get to this other area for food.
You, the developer will have to untangle the real security concern from the business concern.  If the requirements can be expressed in a way that utilizes terminology form different specific domains, then this blending can be stopped.  And we will reduce the needless smashing and untangling of concepts all because it was thought to be simpler.