First of all, you shouldn't be designing a system based on a few meetings with end users. In fact you shouldn't be involved with the requirements phase of a project, that's for the business analysts and end users to work out.

Second phase should be your technical requirements, this is where you will start to work with the business analysts to come up with a solution to the requested specification.

Now is the important part. Make sure you understand both the end user requirements and the functional requirements, there's no use you starting out something only to find it didn't meet users expectations. Speak up if you don't understand something.

Now, time to hit the editor. But my approach is to never write real code, always write an absolute stack of comments first, do it in pseudo code if that's easy for you, whatever it doesn't matter, as long as it's clear and easy to read/understand.

Once you've done your comments you can start either a) writing your test cases b) writing the implementation.

Depending on your environment you would be best starting with (a) but sadly most start with (b) and then try force the tests to meet the implementation. Frankly speaking though, if you were part of a large company there would be a department writing the test cases for you before you even start doing anything.