The time has come. We know how ideal requirement should look. We checked a model that proved to be the best so far several times. Enjoy it:)


The high quality requirements include:


1. There should be Wireframes for each page unless the page is plain text or has 1-2 functions featured.


What is it?

Wireframes is a schematic image of a site/application page. It shows all the elements of the page and serves as a compass for a designer and/or fronted developer.

Why we need it?

To ensure we’ll not miss anything and put everything in the right place from the very beginning. You know, when you’re building a house, it’s very easy to add a socket at the stage of building electricity, but it’s not easy and takes longer to do it when the walls are already painted.

How to do it?

We recommend Balsamiq or similar tools. This program is very convenient because it has prepared objects. You don’t need to learn how to draw, you just drag and drop the objects you need and manage them in the correct way.

Can you prepare it without developer’s/PM’s help?

Yes. No doubt:)


See example of Invites Mockup prepared by a Product Owner of Poli.sh project:

mockup example


2. Detailed descriptions.


What is it?

The best detailed description is written with the help of gherkin syntax https://github.com/cucumber/cucumber/wiki/Gherkin. It enables you to consider all possible situations and can be used as test cases for a tester.

Why we need it?

  • To foresee and develop all the scenarios that are sure to take place on the site.

  • Wireframes do not show the connections between each other explicitly and do not present different ways of using the page. Gherkin descriptions do.

  • To ask/answer less questions. You want to be asked all questions from the beginning, right? We also don’t want to distract you all of the time.

  • To prevent misunderstandings. “Oh, we thought that this button will lead there and to redo it will take another 2 days” - that’s what one can hear/read if good descriptions are not provided so include them to the contract and sleep well.

  • Not to miss details. You’ll already have the conditions of acceptance of work and will not get stuck adding minor things you forgot about, like email notifications, for example.

  • The last and the most important: to know how much time and maney it will take.

How to do it?

First, read about gherkin and second use our explanations below :)


Gherkin syntax has the following parts:

1) Background: here you mention the user roles, the explanations what different objects (buttons, fields etc.) mean on your wireframes. Background is usually prepared for several scenarios.

2) Given: what are the conditions under which your user will act in the following scenario. Thus, we write Given for each scenario.

3) Scenario: represents actions and has such parts:

  • title

  • When=if

  • Then=results


Please see the example:

**Background:** product list page, which has products such as candy, chocolate
      and cake
      User Mary (no staff rights), Ben (has staff rights)
      Button BUY under each product
      Basket, which contains the products bought
      Thank you static page

 **Given**: Mary is registered and has added her credit card to the site. Mary has a valid     card.
 **Scenario: Mary buys a candy** 
      When Mary goes to the product list page 
      And clicks on BUY button under the candy product, 
      And goes to the Basket
      Then Mary is redirected to her Basket, 
      And shown the purchase details, 
      And is requested to confirm the purchase, 
      And is redirected to Thank you page
      And receives an email confirmation.

Check out more examples here. This presentation can also come in handy.


Can you prepare it without developer’s/PM’s help?

You can definitely prepare a draft because it’s much faster that way. Of course, developers team will have questions and prepare their edited version for you to accept it. Or at least help you to come up with them.

If you have standard functionality on your site, it can definitely be described by a Project Manager or Team Lead, and will need to be just revised by you.

If you work by sprints, the gherkin descriptions can be created by the whole team.


Roman Seniv, on of the leading Project Managers in Ukraine, came up with a very good metaphor about the high quality requirements necessity. Imagine that the requirements are apples and the project is juice developers need to build from those apples. If the fruit is rotten, the juice won’t be tasty. Of course, chiefs (=developers) can add spices to make it smell and taste better, but no way is it going to be a quality product.


So, we wish you to come up with only tasty apples to receive the best juice for your users!


P.S. We are working in the area of Python/Django web-development and offer web-development services. Since we wrote such a good article for you, I think we deserve that you give our juice a try. I promise you’ll like it!

2015-08-21