You wouldn’t build a house without a blueprint, would you?
Have you ever daydreamed about building your perfect house? You know exactly what style of home, how many floors there would be, and how the kitchen is laid out. You’ve spent so much time thinking about it, you imagine you know exactly what it would take to bring that vision to reality. At first thought, it may seem that building the home doesn’t seem too complicated if you have a general idea of how houses are built. You need a foundation, framing, plumbing and electrical, drywall and paint. That seems pretty straightforward, and you’ll just need to find a general contractor that will make it happen.
It would be fantastic if it worked out that simply, but in reality, there are a lot of design decisions and constraints that will need to be considered. In the days of HGTV, DIY Network and YouTube tutorials you may feel like you’re well equipped to tackle anything that comes your way and you can make these decisions on the fly as you go along.
Unfortunately, there are considerations you may not be aware of that an experienced professional can easily spot such as what type of permits does your town require, how far apart do the electrical outlets need to be, what type of HVAC system do you need for the size of the home, should you risk finishing your basement depending on the water table, what are the property setbacks? As these questions arise, your simple plan suddenly becomes much more daunting.
A lot of these issues can be planned for by working with your architect and general contractor up front to build a plan and mitigate any of these issues. Both of these professionals work their trade daily and can offer solutions that will better fit your end vision and will do so less expensively while handling them in the planning and design phase.
Now there’s a lot less sweat and physical exertion involved with web development, but planning is no less important. You have your vision and goals in mind for a project but until everyone is on the same page and working toward that same end goal, the path forward may be clouded by assumptions and miscommunications.
How can you plan for requirements with your technical team?
When you’re working with an analyst or technical architect, they will ask you questions along the same vein as your building architect - what are your project goals, are there any technology constraints that need to be accounted for, do you have any third-party software that needs integration, what are your corporate standards for security, are there any other current or future projects that will leverage the same project?
All of these questions spur further conversation that will allow your technical team to have a better understanding of the project and help you consider the details of how exactly your project will function, if it will meet your needs, or if there are other details that need to be considered.
Depending on the complexity of your project, the technical team will take the outcomes from these conversations and produce functional and/or technical requirements that cover, in detail, the functionality and technical aspects of your project.
As you can probably infer from the name, functional requirements will cover what functionality your project will have. The document may detail items such as how forms work on your website – what field types and validations there are, what happens on successful and unsuccessful submittal, should the data be stored in an external CRM and if so what is the mechanism to do so. This level of requirements is generally kept at a higher level – discussing what the project must or must not do while not drilling down into the weeds of how technically these goals are to be accomplished.
If you’re following along, you can probably guess what technical requirements are. These are more analogous to the home blueprints from your architect. Those forms that were covered in the functional requirements can be further expanded on here – what client and server side validation should occur, what (if any) libraries that are being used? Where in the database is the information stored, what is the schema for the database table or are we reusing an existing table with a different source flag? What API does the third-party CRM expose to send information to, and what happens if there’s an error sending the information to the CRM?
These two documents will help ensure that there is a lot less ambiguity while building your project and that everyone is on the same path moving forward. With everyone working off the same set of plans, we can better ensure that we understand your needs and are building the functionally to make your project a success while staying on time and on budget.
Have a project that needs a guiding hand? Let’s talk.