The simplest solution might be a rope with a knot, or I can upgrade my swing by making a seat out of a piece of wood. Though two ropes and a nice wide board would really improve my swinging pleasure. But I can see how it would be a bit more expensive with the bigger board, two ropes, and all. All three solutions support a "swing from tree" task, but have different costs and comfort levels associated with each.
When deciding how a particular task is supported in our software, we go through a similar process of looking at possible design solutions and then selecting one that's both consistent with our product and advantageous to users. We use the description of this solution as our final requirements. Then we review, approve, and drop those requirements into the project plan.
Each one of the possible solutions represents a solution at a different scale. Understanding the scale of the chosen solution among the possible solutions gives us flexibility with scope later on. Instead of dropping a feature outright, consider reducing the scale of the solution. To begin to understand and manage solution scale as part of your requirements, you'll need a little more information than you had in the past.
A user model conveys our understanding of the users. Refer to user roles, profiles, or personas from the user-centered design community, or use actor-goal lists from the use case community. In either case, you will need some understanding of the priority of these users. For example, which users are most critical to the success of the software? You'll also need to know a bit about the users' knowledge. How skilled are they with using software? What level of domain expertise do they have?
A task or workflow model conveys the typical workflow of users as they use the software. Task models or use cases work well to describe workflow. No matter what sort of model you choose, you'll need to understand user tasks exclusive of the technological solution—just as a task like "swing from tree" implies but doesn't dictate a particular solution. To manage scale, you'll also need to understand how frequently those tasks are performed and how critical they are to the success of the users.
When searching for features that are good candidates for reducing scale, look for lower frequency tasks performed by lower priority users with strong computer or domain skills. Simply put, a feature can be a little rough around the edges if it's used infrequently by a smart user who isn't one of the user types we really cater to. A feature like this may be a candidate for a "knot on the end of a rope," as opposed to the "two-roped seated swing" we initially put into scope and estimated.
Yes, I know it's usually not that cut and dry. But, knowing users, tasks, the frequency of each task, and its importance sure helps find opportunities to scale. To act on scaling opportunities, you'll need to be good at proposing alternative and cheaper solutions that help those users accomplish their tasks and meet their goals.
While this helps to cut scope as a release draws near, these are important details to consider when initially scoping the project. For each proposed feature of the product, consider the user and task supported. Consider the possible range of design solutions for that user. Is the solution chosen in line with the user and task supported? Are we spending more time building better solutions for our most important users engaged in their most frequent and critical tasks? Consider deferring detail designs until closer to implementation time.