Requirements are a lot of fun due to their sheer variety. "The system must support Active Directory" is a requirement. "Add a column to the database that indicates deleted or not" is a requirement. Both of these are perfectly good requirements - assuming someone actually wants them. However, your customer is probably going to look at you funny if you talk about internal system requirements (e.g., that deleted flag in the database), and your developer is probably going to ask for clarification if that Active Directory requirement shows up.
Because testers talk with so many different groups - customers, product management, development, support - it's useful to know how much detail to express in a requirement.
For example, the customer may have a requirement that users be grouped and reported on by company.
The product manager would express that requirement as needing "company" on the signup form and a report in the administration section called "Users by Company".
The designer would express the requirement by adding a field to the signup form (just under last name) and a simple list report.
The development team would express the requirement with several tasks, such as: add a field to the database and migration script for deployment; add a field to the signup form; add a report including logic to handle legacy users.
They're all requirements; they're all the same requirement. And they're all correct.
Requirements should be expressed to the granularity that the person expressing the requirement understands the workings of the system.
In a nutshell, when you're talking to someone, talk to them about requirements in a language and at a level of detail that person will understand.