Documenting requirements for a Lotus solution

Lotus being a pack of technologies, it is challenging to come up with a document that captures requirements in a format that can be easily translated into design. In the ‘Good (but not so practical) Real World’ we should not be worried of the technology while the requirements are documented. Since in most cases we approach requirements with a particular platform(s) / technology(s) in mind, it is practical to adulterate requirements with some technical details. The objective though should be to document requirements in a format that is flexible for design (Java/J2EE, lotus component or something else), development (RAD, testing tools, language used for development) and implementation and most importantly - Change!

Suggestion on the documentation part would be to completely cover the requirements and clearly define the scope (without duplication of effort at a later stage of a project). Some key aspects that need to be included in this requirement documentation

• Use Cases
• User interface Details, including fields
• Access/State Matrix - Depict the state of a document/data element in different modes - at various workflow stages - for multiple user roles. This can be really handy at any stage of the project.
• Requirements that are based on the out-of-the box platform capabilities (Replication, Security etc)
• Non-functional requirements – Sizing, availability, scalability, performance related etc.