So you want to start an IT project? Maybe you’re not a developer, and you’re now browsing the market for your options, and you decided to outsource the job to a software development company. Maybe abroad?
Okay, so the portfolio looked good, they seemed like a reliable partner, but on delivery things still, don’t go as expected … You’re not very satisfied with the outcome of their work, frequently thinking:
“That’s not how I imagined it. If they know their work, how it could go so wrong?”
Good question, but the answer is simple – “Requirements.”
If you want to avoid situations like this in the future answer these three questions:
- Did you explain to them what your business is about?
- Did you show them “How you imagined it” and made sure they understand it the way you do?
- Was there any requirements gathering meeting?
If you answered with at least one “No”, you are in the right place. This article is about essential things that will help you to learn about preparing a specification for a software company. So let’s start!
Share your context
First thing’s first. You’re in this business for a long time or just deep into your idea. Therefore you know it all, know all the answers, and went through and through over the concept. But people who will work for you are new in your business. Sharing the same context means understanding the same words exactly the same, and also making sure that you know the rules that apply to these words. It’s good to give a proper explanation, so to check if the other side can answer the questions below:
- Do I know what the business is about?
- What’s the goal of the project?
- Which aspects are essential for the project? And which can be skipped?
- What are the deadlines?
- How will the product earn client money?
- Who additionally will be involved? (i.e., customer, salesman, administrator)
Checked?
Ok, so now you’re on the same page and can continue in the same context saving a lot of time on explanations in the future.
Types of requirements
When you want to create a website, you probably think that it should be smooth, fast, and nicely designed. Perhaps you want it to look better than the competitors’. Maybe you also have some inspirations you would like to follow. All those things matter and most definitely should be passed on to a software company. But still, how much do they say about what do you really want to achieve?
It’s like building a house. You would start with a number of floors, rooms, and their sizes, type of roof, terrace, choosing a project, etc. And you know what? It’s not that different from software development. Requirements you give for an IT Project can be easily divided into two groups:
Functional requirements – they say what you want, i.e.
A functional requirement for a milk carton would be “ability to contain fluid without leaking”
Example and photo: https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/
Nonfunctional requirements – they say how you want it, i.e.
A non-functional requirement for a hard hat might be “must not break under pressure of less than 10,000 PSI”
Example and photo: https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/
Functional requirements
Firstly, let’s focus on functional requirements. For instance, you know you want to create a website, and probably you have dozens of ideas on how it could look like. Certainly, you can’t wait to share them with your contractor and get the exact thing you wanted.
But please be aware that at this stage you probably don’t speak the same language.
The contractor would like to have flowcharts, designs, tasks, while you want just your website to be modern, good looking, fast, and enable your customers to buy your products. Below you will find a couple of ideas on how to make sure you share the same language and context.
User Stories
User story – a sentence that represents what you want to achieve in developer-friendly language.
So ok how to go from one to another? The answer is easier than you think – meet in the middle. Share your story in a way that the developers will understand it. User Story is a great and simple tool for that.
It goes like that:
As a <who> I want to achieve <what> to <purpose>
I.e.
As a client I want to be able to add my item to a cart, to be able to purchase it
Why this form does the trick?
You’re explaining <who> – user role
Want’s to achieve <what> – explaining the function
To <purpose> – the feature expected
Using User Stories is one of the best approaches on how to explain business requirements to a developer. Just remember to have an open mind and rather than giving a general idea, explain the perspective of what your customer, employee, or you would like to achieve and how. You will be surprised at how efficient it is.
Wireframes
Wireframes are just sketches where you do not focus on design, but pure functionality and arrangement of elements on the website or an application.
A picture is worth a thousand words. It sounds a bit cliche, but remember there’s no better way to share your vision than to transfer it directly to a paper, or a simple drawing tool. Feel like you want to speed up the process? Feel free to use the tool like Balsamiq or Axure and take your wireframes to another level!
Wireframes also allow you to put your requirements into perspective. They will picture where exactly you see a button, photo, or any element of your website. Therefore it’s worth a lot more than a thousand words when working with an abroad company!
Using sketches, even done by a hand, also helps you think the same as developers do:
- Is there a clickable link, menu item?
- What happens when I click it?
- How the next page will look?
- Do I have any data I want to have automatically transferred from other services? Or do I want to put them in?
And if you ask me that’s pretty neat!
So far, all projects I’ve encountered which had that kind of requirements acquired (user stories, wireframes) were successfully delivered! And had a significantly lower level of misunderstandings and of course, always helped the client and developers team to be on the same page.
Non-functional Requirements
Also important but be aware that these are conditions rather than the exact scope. So if you considered only below, think once again what you want to achieve!
So…you want your site to be fast, efficient, and nice-looking? Sure! It’s very important for the contractor, but try to be more specific and make sure you explain what it means to you. A quick cheat-sheet of explaining the non-tech requirement for tech people 🙂
Some final tips?
- Make sure you paraphrase when giving requirements – it’s the ultimate way to make sure you were heard, and the other person got your ideas right.
- Do not over-engineer. Focus on what you want to achieve and what are your requirements. Then spend some time finding the best experts, let them do their thing, and use their experience.
Key takeaways
- Business and development must share a context to get along. Therefore remember to be explanatory and aware that both sides see the project from 2 different points of view.
- Try to speak the same language if you want to be sure they understand.
- Speed up the process using quick sketches/wireframes/user stories.
- Paraphrase to make sure you’re on the same page.
- Share your goals, not the solution. The experts will know how to achieve them.
