As I've recently answered with regard to a question about how to write a Software Requirements Specification (SRS) for a portal, you write an SRS the same way regardless of what the SRS is for.
Therefore, a far better question, and perhaps what this questioner actually meant to ask, would be, "How do I find out the requirements for a non-profit organization having three different databases which do not collaborate?"
While I can't know the specifics of the questioner's individual situation, I can state with great certainty that focusing first on the databases virtually guarantees failure. The databases are a presumed solution to some problem, opportunity, or challenge. The databases probably are not collaborating because:
- The organization's REAL problem, opportunity, or challenge that provides REAL value when addressed appropriately has not been defined adequately.
- The key causes of the problem, opportunity, or challenge have not been defined adequately. Existing database contents, structures, and relationships probably are one of the key causes.
- The REAL, business requirements deliverable whats that provide value by addressing the problem, opportunity, or challenge have not been defined adequately.
- The product/system/software how to meet the REAL business requirements, such as databases and collaboration among them, has not been defined adequately.
- The product/system/software how has not been implemented adequately.
Once you've identified what needs to be accomplished to provide the organization the value it needs, then and only then is it worthwhile to worry about how to accomplish it--a product/system/software whose design is described in an SRS.
The database contents, structure, and collaboration are part of the design and are described in a separate SRS section. More importantly, the SRS should be describing the functionality whereby the database contents are obtained, entered, validated, linked, retrieved, and manipulated/formatted to enable meeting the REAL business requirements.
Dig deeper on Penetration Testing
Related Q&A from Robin F. Goldsmith
Requirements management and the requirements process are sometimes used to mean the same thing, but customers should be aware that there are ...continue reading
To prevent feature creep, product requirements should satisfy the actual business requirements. Creep can occur when product requirements are ...continue reading
Testers often complain that software requirements specifications are too vague, but verbose requirements can have the negative impact of being so ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.