SQL Server Third Party Application Requirements Document and Checklist

By:   |   Updated: 2010-01-25   |   Comments (2)   |   Related: More > Database Administration


Problem

In August 2009 I wrote a tip concerning checklists for third-party applications running against Microsoft SQL Server.  I thought it was a good time to revisit the topic and provide an added bonus: a requirements document that you can download and customize for your own uses. 

I'm a big advocate of doing the work once and sharing the wealth of collective efforts with the SQL Server community, so here you go!  Obviously not all the components I've included in the Requirements Document will be appropriate for your environment, but I'm sure most of them are.  Just as likely there are items you're concerned about that are not covered.  I think we would all be interested to know how you are planning on enhancing this document to fit your needs.  Please do so in the comments section below.

Why did I draft this document?  Because more often than not, I would be notified by email, phone, or instant message to the effect that "we have a new application going into production next week and it needs a SQL database."  Usually followed by one of the following additional comments:

  • "...can you create one somewhere for me."
  • "...the vendor needs System Administrator rights so he can create the database."
  • "...just give me rights and I'll take care of it."

Obviously these are questions that the DBA (or Database Professional in smaller Information Technology departments) should never need to face blindly.  That is another reason why it is important that these specifications are requested as early in the vetting process for new applications as possible.  Optimally, these items are listed in the general documentation that is sent out during a Request For Proposal (RFP) to the pool of companies that you're interested in.  More often than not the database platform is not necessarily considered - particularly in situations when it is common knowledge that you may have capacity on a non-dedicated SQL Server.  In these situations, it is assumed that if there is capacity available - it is available for any product (after all, it's just storage space, right?)

Solution

By having some form of standardized Requirements Document specifically geared towards the relational database platform, and in this case Microsoft SQL Server in particular, you accomplish a number of important goals:

  • The DBA is provided with the information you need for load balancing.
  • Understanding in where, from a security standpoint, the database(s) may reside:
    • If the vendor requires an escalated level of rights (think SQL Server-level role permissions or local access to the SQL Server host) then you know that this database is not a candidate for a consolidated (aka shared) SQL Server instance.
    • If the vendor requires a specific collation for the SQL instance this may require you to dedicate an instance for just their product's databases.
    • The vendor may require an edition or version of SQL Server you do not have capacity for in your environment, even though you may have capacity that is not consistent with their requirements.
  • Storage requirements.  We pre-size our databases for an estimated three annualized cycles of growth to minimize external fragmentation and reduced administrative overhead in monitoring for possible auto growth.
  • Impact on the SQL Agent's job system.
  • The need to stage additional environments for non-prod versions of their databases (train, test, development, or stage as examples.)
  • From a non-DBA perspective, asking these questions initially also fosters awareness towards the architecture, planning, and costs that are associated with the database platform. 
  • If you do follow through and purchase an application, and these questions are already answered, your security, database administration, and storage teams can proceed with their tasks once the project goes live in a more efficient and effective manner.  Login information is already collected, as are storage requirements, database hosting requirements, hardware requirements and the like.

The SQL Server Requirements Document template can be downloaded here.  In this zip file I have included three versions MS Word 2007, MS Word 97-2003 and PDF.

Please customize it and use it as your own and if you have some changes that you think everyone can benefit from please enter these in the comments section below.

Next Steps


sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip



About the author
MSSQLTips author Tim Ford Tim Ford is a Senior Database Administrator with MindBody.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips


Article Last Updated: 2010-01-25

Comments For This Article




Monday, January 25, 2010 - 7:08:20 PM - SandraV Back To Top (4788)

Thanks for updating and prettying-up this list, Tim. A few months ago, I used both your original list and another similar one that I found as the basis of an application scorecard for a product evaluation we were doing. Since our database professionals are likely to also be the application analysts on a project or selection team, my list goes a little deeper into issues that are more application and project focused but I think I had about 95% of what's on your current list on my scorecard. I'll probably customize your current list to try to bring some process to my own Systems department who has been known to cause as much pain as the business with their "We just bought this new tool and it has a database. Where can you put it?" questions. And, that's if when tell me. VMs do tend to popup like mushrooms around here.

I'm curious though.  Do you often find that a vendor can give you IOPS requirements?

Monday, January 25, 2010 - 6:40:54 AM - --cranfield Back To Top (4778)

great tip!  Nice document too. I will be using it.

 

cheers














get free sql tips
agree to terms