I have doubts regarding the process of collecting customer expectations and turning then into a functional document that we both can follow up to measure if the project reaches expectations.

I have a rough idea in this regard - such as: 1 - The document should specify the different pages and their content 2 - The document should specify what actions the user can do in them 3 - The document should specify what sort of behavior the project should have when facing errors

But I am not sure about this.

Any help, tutorials, videos, books or whatever related will be very appreciated.

Update My client asked for a website and sent a PDF with a design of what he wants. The design showed some parameters from where I could extract the database requirements and the approximate logic I would have to build. There are even pages that do not appear in such document, like the admin section which they obviously need.

My question is about a document, I believe it's called functional document, that would be build before starting to create the software. In that document there should be specifications regarding:

    • Database entities

    2.1. - How they relate to each other

    2.2. - Parameter validation (min length, max length, Names without non-alphabetic characters, etc)

    • Application pages

    2.1 - Content

    2.2 - Actions

  • 1
    Hi Hector, welcome to Freelancing.SE! I'm not sure I'm following what you're asking for, as your question is currently written. Could you edit it to include maybe some examples of what has gone wrong, and what your expectations are?
    – Canadian Luke
    Mar 6 '15 at 18:39
  • Can you be more specific? I have experience with writing all types of specs, but I am not sure what you refer to.
    – Peter MV
    Mar 6 '15 at 19:35
  • I added some details. Hopefully that clarifies my question. It's hard for me to be more specific because I am not even sure what's the normal procedure here, I just have the feeling that there should be some document that clarifies the requirements. Thanks for your time btw! Mar 6 '15 at 20:09

I would not tend to go into a lot of detail before a contract was signed. What you are describing is a lot of work, and you should get paid for that. Your client could easily take a detailed functional spec and give it to someone else to develop into a product.

If you are working on a RFP, keep the specifications high-level and general. Save the details for after the work's been awarded to you.

These types of documents have many names: Functional Specification, Software Design Document, System Requirements Specification... and the content is similar.

For the system you seem to be developing, there might be two documents (or even 3):

  • the front-end specification (UI Specification), which would specify each individual screen, what functionality each screen contains and how the user interacts with the functions. This may also include workflows.

  • the "back-end" specification - which contains what you're talking about - the database schema, data processing, and any software that links the front and back ends together. If there are a lot of subroutines or subsystems, each of these might require their own specification document.

Of course, this all is fluid and depends on the processes you or your client's company use to develop software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.