Without requirements or design, programming is the art of adding bugs to an empty text file.
You do have your Plan well under way... right?
Software does not exist in a vacuum - it exists to solve a customer’s problem.
Answering these questions help you as you start to flesh out the requirements.
There are may ways to capture requirements, but personally I find simple user stories to be an effective starting point:
As <role> I can <capability>, so that <receive benefit>
User stories can help you (and the development team) make sense of the functional requirements without needing to over structure the problem description.
Broadly speaking functional requirements define what the system is supposed to do. Whereas non-functional requirements define how the system is supposed to be.
Okay so that’s a little abstract. Try thinking of the requirements as:
Another way of thinking about a system’s non-functional requirements is as qualilities of the system.
You get the idea.