When you read requirements, do you ever wonder "How will an end user get value from this?" or "What does the user do with that information?" or "How does this detail matter in the big picture?"
You may be missing some usage scenarios. Usage scenarios tell you why the user is doing something. Where use cases start with an actor, and describe a series of actions required to complete some unit of work, the usage scenario, starts with a goal and an initiator, then details the actions and outcomes.
A few years ago I was on a project where we had a requirement to build a Cash Balances report. Our requirements described the format and content of the report, as well as the criteria for initiating the report. We had all the information we needed to build the report, but did not understand the reason the report was necessary, since the cash balances were displayed in several other places in the system. When the analyst went to ask the user about how the report was used, he wrote the following usage scenario:
In order to ensure portfolio managers can have updated cash positions at start of day <goal>, every morning when the reporting system is available <initiator>, the administrative user will run the "Cash Balances" report <action>, then input the cash balance for each account into the portfolio management system <action>.
Understanding: the goal of this usage scenario is "in Order To…" – which has little to do with the report that the user runs. Wouldn't an interface be better? Why would I even build a report? We learned that the cash balances that we were looking for actually came from a different system than we thought, and were only important for updating the portfolio system. We also learned that this manual update process took about 2 hours every day, and delayed the start of trading for the business unit.
Outcome: We built a fully automated interface, at 40% of the cost of the report, and saved .25 FTE effort ongoing in the business unit.
Understanding the context in which a feature or capability will be implemented is as important as understanding how the feature or capability will work. Requirements without an understanding of the business context in some manner are incomplete, and often lead to poor solutions.
In this case, we learned that the current business process could be significantly improved for less cost then supporting the existing process. This is an opportunity that would have been missed if we had not taken the time (2 hours) to understand the business context of the requirement.