One way I used to think about requirements was by making a distinction between facts imposed on the developers and design choices that were left to the developers. The facts were a way of thinking about the requirements.
Since then I have started to think more in terms of Constraints and Design Choices, mainly because the word constraints allows for more nuanced thought.
- Constraints are negotiable
- Some constraints are explicit
- Some constraints are implicit - and lots of problems arise from these culturally known items
- Constraints change over time, sometimes being relaxed, other times firming up
- New information can totally blow away existing constraints while imposing others
The implicit side of constraints are the most interesting for me currently, since these are the ones that are never written down. Not because people do not take the time to write them down, but because it never occurs to anyone that they need to be written down - after all it is just the way we do things around here. Since everyone know it, there is no thought that there is anything to write down.
The problem shows up however when someone form outside the culture gets involved with the development team. Now the outsider gets a whole lot of surprises as these implicit constraints get surfaced as disconnects and contradictions.