It is not possible for software to be successful if there is no consensus on what the software is supposed to be doing. That is where requirements come in to the picture. There are four basic types of requirements; story boards, scenarios, walk-throughs, and user stories. There is not a lot of difference between them.

• A walk-through presents the requirement as a sequence of steps that the user takes.
• A scenario is a more situationally oriented form of a walk-through.
• A story board is like a walk-through with rough mockups attached.
• User stories come from eXtreme Programming where the requirement is written in the narrative voice of the intended user.

Sometimes it is easy to get lost in the requirements phase of a project. A non-trivial project can have a depressingly large number of requirements that feel like an impossible laundry list of wishes. That is why information architects like to formulate a mental model where requirements are tied to design personas through a hierarchy of needs.

• A design persona is where you describe a typical user.
• A requirement is important if it can meet a need of a design persona.
• The more needs that a requirement can meet or the more important the persona, the more strategic the requirement.
• You will want to schedule the highest priority requirements for the current release of the project.
• Less important projects should be scheduled for future releases.

Don't be tempted to try to get them all in one release. Requirements also come with a lot of standard features.