With stakeholders identified, discover and record the needs of stakeholders in their language. Each stakeholder has a unique perspective and has a set of needs that are to be satisfied by the system.
With the stated if imprecise needs of those involved, it is time to decompose the existing system into what it is, what it does and when it does it. These three perspectives support the identification of requirements that might not be obvious when thinking about the system in an unstructured fashion.
Capture components of existing and desired system. This is a source of many unstated needs since the current system usually performs some service even if badly.
Map functional needs into feature sets. This is where the informally articulated needs are distilled to formal requirements clumps called features. Requirements must account for every interaction between the system and elements of its environment. The environment is divided into actors that act on the system.
Map temporal needs into states. This tells us when certain operations are to be performed relative to others. This process taps into many otherwise unspoken needs of the system.
This leads naturally to prototyping scenarios (or storyboarding). Here the principal paths through the application states are illustrated as to how the system will look to an end user. Sometimes the prototypes can be quite involved in the detail to which they emulate the target system. The development cost should be very small when compared to the actual projected development. Finding problems at this stage can avoid what would be huge costs in reimplementation if caught later in the process.
Map Architectural needs into straw man logical architecture. This is a diagram that shows logically how functions the system is to perform can be divided into parts. Being logical it does not commit to technologies. These parts must interact among themselves and this interaction determine the information that must be shared or transmitted.
As you can imagine, complex systems contain huge amounts of technical information that is captured in the process and must be recorded in a way that allows human and machine processing. This is the source of the need for a requirements management or system modeling system.
Even a modest system that you may think does not require such rigor can have a surprising number of concepts that are confused among stakeholders and must be reconciled to each other.
A model based requirements tool should be used to capture all requirements related information. Further, if the process is to result in a family of products then a pattern based modeling approach should be considered.