Post: #5

My suggestion is that, as you discover them, write down your very specific requirements. For example, saying "Pre-T2A, T2A, or UO:R (with only one facet) look and feel" has a lot of broad connotation... so narrow that down as specifically as you can. Then collect all those requirements in one document/wiki so that when you start building it out, it can be referenced.

My final word of advice is: Requirements are not just a statement of system behavior, they should also be explained as to why they are a requirement, and whose requirement they are.... this is very helpful when you discover limitations and need to decide whether that requirement should be (or can be) changed or not. Don't hesitate to add "limitations" to the list of requirements.... for example, maybe something is impossible to do (perhaps because the client software doesn't handle things that way) so including that detail as a requirement, imposed on you by the client software will help so you don't forget about it.

Once you start building the shard, you should link the implementation back to the requirements so you know where they got implemented. You should write a test case for your requirements to ensure you know how to prove they are working, and you should ultimately have a test plan to be able to run through all the tests in a reasonable amount of time.

So:

1. requirements (with details on whose it is, what is is about, and a link to where in the code it was implemented)
2. implementation (with details on which code files were used to implement the requirement, linked to a test case to prove it works)
3. test case (with explanation on what steps to follow to test the implementation and therefore the requirement)
4. test plan (a guide to step by step through all the test cases in a efficient way)

My suggestion is to store all this information in a wiki so its easy to collaborate on and manage