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).