While working with outsourcing clients, a common problem appears, is the functional specification. Clients generally don't want to spend much time creating specs, try to write ASAP, which results an unfinished spec.
While developing developers suffers a lot. First, it often gets confusing, the developer can't understand exactly what the spec is saying. Second, during the development (and also after seeing some demo), client discovers new features, which results much re-engineering on the code, as this is too late for adding new requirements.
'Traceability Matrix' might really a good solution in this case. What is 'Traceability Matrix'? In short, this is the simple list of features, something like the product feature list in the web sites (well off course TM has some more features). This is easy for clients as it requires less time for them to mention. Since clients are too busy to have time on spec, we can start work on specs, as we get the list of features. A smart system analyst can forward and elaborate the requirements in useful way using 'Traceability Matrix'.
• This is the simplest requirement document. So keep it as simple as possible.
• Include features in bullets, if necessary group the bullets, according to modular requirements.
• Common Functions: Consider special terms, to specify commonly used requirements among several cases. For instance, such special term can be “CRUD”, which says Create, Read, Update and Delete operation in any entity. While writing requirement documents, you can use this commonly used features in multiple cases. Like: User CRUD, Product CRUD, Books CRUD etc.
• Common Scenarios: You can also consider special terms for commonly used application scenario. For instance, a special term can be “Create Secured Record”, which tells, 1. Click “Add item” button, 2. The user will be redirected to “Add item” page, 3. User inserts data, 4. User submits data, 5. User provides “security text/code”. 6. User gets back to the caller page.