To kick things off, the software company should visit the client to observe their processes and procedures. Upon a visual inspection, new technology requirements will be more clear and tangible. The employees should be watched to find improvement areas. This is also the time to explain how our information system can help them save time and money. If the employees don't know that certain technology exists they can't request the update during the prototyping stage.
Once the software company has viewed the facility and met with their management they will have many questions about their budget, time frame and system requirements. Asking for surveys and conducting interviews will help the software company take the next step in the process. The interviewer must ask the correct questions to determine the needs of the customer and the users of the system.
Prototyping starts to get the users involved by giving them a basic version of the system that hasn't yet been implemented for them specifically. This basic version will allow the user to enter items, customers and vendors to see what they like and dislike about it. The comments and requests will be documented for the programmers to see when building the system. Each system is unique to the company using it so that it reflects their company policies and procedures. Prototyping is the perfect technique to find out what the customer is most interested in. It also describes the portions of the system that the user doesn't need because it will save them money on the price of the system.
Once all of the visits, interviews and comments are received and documented it's time for the key-project-employees to meet together and discuss the best approach to building the system (Joint Requirements Planning). These employees include IT developers, end users, managers and a facilitator. They discuss the needs of the customer, how long it will take and how much it will cost to give them everything they asked to have.
During the interview process it's smart to ask employees and end users how important each request is to them on a level of 1 to 10. For instance, the end user might ask for a slick interface design but it's only a 5 on their scale of 1 to 10. That additional cost may or may not make it to the final drawing board.
Let's analyze what we've got. What's required, what might be a nice addition and what's at the bottom of the list? How does each requirement affect the final budget? Is it even possible to complete the project requested of us? All of the questions are discussed and analyzed during this fact-finding stage. If 10 steps are agreed upon, a time will be associated with each step and a cost will be associated with the allotted time. If the systems analyst decides that it's still worth the return on investment then it will move to the next stage of the process.
The completed report of numerous facts is documented and turned in through the use of a Requirements Definition Document. It will be a step-by-step process explained as to what will be completed, how long it will take and how much it will cost. By chronologically completing all of these steps the software company and the client will understand each other and have similar goals in mind.
Skipping all of these steps by directly quoting an "information system" on day-one will create many problems along the way. It will be unclear for many of the employees on the project because they don't understand exactly what the customer wants.
Whitten, Jeffrey L., & Bentley, Lonnie D. (2007). Systems analysis and design methods, 7th edition. Boston, Mass.: McGraw Hill.