Answer to Question 1
Kerberos
Answer to Question 2
Document and update requirements. During design and implementation, when the product is seriously taking shape, we discover many missing or conflicting requirements. Usually short conversations clear the issues away, but leave no trace for the future. Avoid this. To wit, an oral requirement is not worth the paper it is written on.
Document sources. As accurate as a requirement may be, we must be able to trace the sources. First, sources allow us to verify the requirements. Second, referring to sources is the only way to resolve inconsistencies both for the current project and future changes (or maintenance).
Separate requirements into distinct units. Requirement statements must be atomic. In other words, each requirement must be written in a way that a simple True or False can verify the essence of it.
Uniquely identify each requirement. Assign a unique number to each requirement. This is the only way to make references unambiguous. Assign numbers sequentially, do not build any meanings in them and do not reuse them if a requirement is dropped.
Verify requirements and document verifications. A requirement must be verified by at least one (human) source. A second verification is highly recommended, and more verifications are so much for the better. Questionnaires are the best tool for verification.
Prioritize requirements. Assigning priority gives a general idea of the requirement's importance to the business.
Classify requirements meaningfully. Government agencies and many companies have their own mandatory standards and formats for SRS (Software Requirements Specifications) documents. If you can choose a format, there are a number of popular templates for organizing requirements.
