First off, you're absolutely correct in trying to nail down the requirements before choosing. It sounds like there are a couple related problems that you're try

First off, you're absolutely correct in trying to nail down the requirements before choosing. It sounds like there are a couple related problems that you're trying to solve. 1) You find the database design difficult to understand, 2) you're trying to understand and get sign off on functional requirements and 3) you're trying to write up a design for a technical solution. For 1) see if you can get an ER diagram so you can see the relationships. You may find that additionally you need to document sections of the db schema because you don't understand what certain tables represent. This can be done in a wiki or in the code or both. 2) Can be done using user stories or tickets, but for complex work it's best to write up a business requirements document containing the functional requirements (what needs to be done, not how to do it). There are templates and examples readily available, just adjust for the level of detail you need. This is what your boss should be signing off on. 3) You can probably avoid creating technical specs at the moment. Their target audience are developers and these specify the solution design. Unless you have a real need to choose one solution over another, it's often best to let the developer working on the problem to choose their own solution. As an aside, you mean pseudo code not sudo code. Sudo is a linix/unix command