Developing Project Requirements and Specifications

Project Talk

I know, everyone’s favorite subject!

I also know many developers skip over this step. (Don’t be one of those people!)

What Are Requirements

Requirements document what is needed and should not explain how it will be accomplished.  It is a list of wants and needs.

What exactly is it that your client needs.
What is expected of you as a developer.

This is typically the responsibility of the client to create, but I have helped numerous clients define these while developing Specifications to ensure I was accurately perceiving their projects accurately.

Don’t just take verbal requirements.  Put them down in writing, even an e-mail, and get the client to acknowledge them.

What Are Specifications

In the simplest terms, specifications explain how you will attain the requirements.

What is it that your solution will do and how it will be composed to do so.

This document is created by the developer to explain to the client how they propose to address their Requirements.  Some aspects will be simply repeating requirements (in a reworded way), this is normal.

Different Type of Specifications

Yes, if we want to get down and dirty and real technical, there are different type of specifications.  Things like:

  • Technical Specifications: “Describes any characteristic of an engineered system that must conform to a specific metric, within some degree of error.”
  • Functional Specifications: “Describes the expected behavior of a software system”
  • Program Specifications: “Describes what the software is supposed to achieve”

“The Program Specifications differs from a Functional Specification in that, while a program specification describes what the system does, the functional specification will describe the manner in which it does it.”

That said, I’ve always rolled them into 1 as they go hand in hand and I find it clearer all together rather than chopped up in separate documents.  This also has to do with the size of the project.

Why Create Requirements & Specifications

In reality the both documents are beneficial for both the client and the developer to ensure that everyone has the proper knowledge of the project and sets the expectations for all.

By putting black on white the reasons and expectation of the work you can avoid a lot of misunderstandings!  Requirements and Specifications also are needed for proper project estimates.

When Should You Create Them

Before even quoting on a project!

If your client doesn’t have set requirements it will be impossible for you to properly establish the project specifications as you won’t know what exactly is expected, so how could you possibly bid on a project with any type of accuracy?

If a client doesn’t have any requirement created, then you should insist on them doing so, or sit down with them and define them together.

I’ve actually been in the situation after reviewing Government Requirements of contacting them and informing them that their requirements were wrong for their objective and guided them to reviewing them so they could attain their desired result illustrating how important it is to write these things down!

Questions to Ask/Answer

Since most small to medium size businesses don’t normally develop requirements/specifications I will normally sit down with a prospect client (yes, before even having the job) and discuss the project as a whole to develop these informally with them and any key project stake holders.

I start normally start the process by defining the existing infrastructure:

  • What type of network (LAN, Wireless, WAN)?
  • Is there a Server?
  • What devices will be used to access the solution
    • What OS is currently being used?
    • What version(s) of MS Access/MS Office will the database be run on?
      • Is Access already installed?
      • What bitnesses will be used?
    • What is the typical screen resolution of users?
  • Who will be the main point of contact?
  • Who will do the testing?

Then I inquire about the project specifically.

  • What is the purpose of the database?
  • What format should be used?
  • Who is going to use the database?
    • Number of users
    • Capacity of each user/group
  • Is there a specific back-end technology to be used?  Who will manage it?
  • Does this database require security to be established?
    • Should user or group level security be established (or a combination of both)?
    • What privilege will they need (read-only, read/write,…, access control, …)?
  • What current tools are you wishing to replace or improve upon?
    • Please provide screenshots and/or printouts of each tool
    • Elaborate on flaws with existing tools. What is it that you would like to improve about each existing tool?
  • What new aspects are you wishing to incorporate (your wish list)?
  • What are the inputs going to be (what data do you wish to track/store in the db)?
    • Create a master list of all the fields required in the database
  • Will existing data need to be imported or will this be a blank database?
  • What are the outputs going to be (what reports, lists… are you wanting to be able to extract – more about reports later)?
    • Gather example of each report
    • Make sketches of the layout of reports that you would like
    • What formats are required (Access reports, Excel, …)?
  • Does the information need to be exported to another application such as Excel or Word?
  • Does this need to be a multilingual solution?
  • What formats are used?
    • Dates
    • Currency
    • Measurements
    • Phone Numbers
    • Addresses
    • etc.
  • What utilities should be implemented?
    • Date Picker
    • Calculator
    • Color Picker
    • etc.
  • Are there any compatibility consideration I should be aware of?
  • Is  there a color scheme that is to be used?
  • Is there a specific font(s) to be used?
  • Is documentation required?
    • In what format?
  • Will training be required?
    • How many people
  • Will support be required?
  • Will maintenance be required?
  • What are the expected deliverables?
  • What is the timeline?
  • What is the budget?
  • Is installation part of the project or will that be handled internally?

Taking Things Further

I like to make a mock-up of a basic form/report that the client agrees to so as to define color, fonts, layout, …  It will eventually become my template for building the rest of the database.  I’ve always found that this completely avoid any issues with clients and hasn’t failed me yet.

I also typically create the data-model during this process as it to is the basis for properly encompassing the scope of work to be accomplished.

Final Thoughts

Requirements, like Specifications, are often overlooked by developers and clients alike as they try and cut corners, thinking that this will save them time/money.

The truth of the matter is that by taking the time to gather all this information upfront:

  • you show a distinct level of professionalism
  • ensured you have the necessary information to provide a fairly accurate estimate and perform your task
  • ensured the client has properly thought things through
  • ensured both parties have a common understanding of the project in its entirety
  • ensure that your solution will properly address what the client actually wants/needs
  • avoid ugly surprises and possibly scope creep

Requirements and Specifications are an investment in the future of the project and, in the long run, save time and frustrations in the long run!

Remember, Requirements and Specifications should always be written down black on white and never simply verbally agreed upon.  This is to protect all the parties involved.