A client asked us to automate his offline paper-based processes. He sent us a copy of the physical forms that he uses.Our team met and discussed how the navigation should be, what major components would exist in the UI. That's it.Problem is, we don't have actual written requirements. With a lack of an actual business/system analyst in our company, what are the steps that we should take to reach the point where we are ready to start developing the system?
First step in analysing a proposed system
requirements;systems analysis
Even if you don't have a business analyst, you'll need to have requirements in written form in order to:have a clear picture of what you are doing. No matter how many times you've discussed the application and how familiar you are with the details, you cannot guarantee to remember everything, and eventually you'll either miss a feature or deliver something else than the client needs.use the requirements in negotiations with the client. The client should see what they will eventually have in an early stage. If they want to change anything, the written requirements will help to see where, what and possibly why the change was made.protect yourselves. People tend to forget a lot. There is no chance that the client will remember every single detail of what you've agreed upon. If this happens, you'll have the document to prove otherwise. It isn't necessary that you write the requirements as a business analyst would. Depending on the complexity of the system and on how obvious it is, even simple diagrams of high-level processes and UI can suffice. If you still cannot have the requirements written, I suggest you build a simple prototype, discuss it with the client and continue working on that (though requirements and prototype don't exclude one another).