Requirements
Introduction
The first thing you should do is to get a clear definition of the system's vision/mission/goal. You have to discuss this issue with the customer (who pays) and understand well what he wants you to provide him. This can be on a very high level such as "I want more people to hit my site" or "A car that everybody would be astonished by" or just a "Faster and quality machine". You must take this high-level vision and break it down into small understandable small bricks – objectives, explaining how to accomplish all that is required (which are not always clear).
The high-level requirements document should be first introduced to the owner who orders the system to define precisely the mission statement of the new system. This document should contain critical success factors (CSF) "as required by the paying eyes". This might be a bit different from what the user will need. Sometimes you might get a critical success factor that is not connected directly to the developed systems such as "No need for helpdesk" or "short learning curve for the technician mending the product" or "target consumers is mainly women". One must understand these issues in-depth and define the implementation in the required documentation.
These high-level vision statements should be introduced (after getting the executive management permission) to the mid-range management and the users. This is for several reasons. The first one is the commitment of the management to the developed system. The second issue is to present the developing team as "bringing modern ears to the company" and positioning the developing team as helping to bring innovation to the company and the employees. It is a great testify "we are on your side and we work together toward a better horizon". It would be wise to listen to what the mid-range management and the team workers have to say on the new things to come.
A good topic to ask the employees is how they think you should gather the information and share their opinion with you including how to implement the system on-site. This is great to improve their commitment to success later on.
Input
Stakeholders ranked at a scale of knowledge, willingness to contribute, involvement in the project, and with the firm activities as well as personal benefits from the specific product deployment.
Process
Meetings with customer people, managers, users at all levels. Get as many as documents the company is using and learn what is good and what should be improved. Talk to everybody. This may be the last time you will be able to talk to them freely. Make a cross-verification, and validation review to understand the organization's political culture.
Make a feasibility study comparing a competitive edge for a better solution. Try to propose several resolutions to existing problems.
Output
Requirements documents describing the following:
Process details
Environment information
User capabilities
Operating environment
Constraints - Design, Logistics, cost, scheduling, parts, interfaces