Recently, at one of the leading Ecom project conferences, a representative of our company gave a lecture on how entrepreneurs should collect requirements for developers in order to get the expected results. The report was a great success with the audience. Here we broadcast the main points voiced by Dmitry at the conference.
About the author
Dmitry, Key Account Manager/Simtech Development
My name is Dmitry, I have been specializing in launching and managing eCommerce projects. I successfully help businesses migrate from offline to online. I managed to work with a wide geography of projects: North America, Europe and Asia. My report is based on practical skills, real facts, and today I will go through one of the most important stages of projects together with you.
You may have already implemented or are just planning to launch a project. As you know, the preparatory stage is the foundation of the future platform. The launch of any project is an investment, where price, timing and quality are very important.
Dmitry
I’m sure many of you have experienced the process of evaluating and collecting commercial proposals. It’s when you write to 50 companies, ask for offers, and then are a little horrified by the prices and deadlines you get.
Gathering requirements helps to specify the tasks for the development team and form a clearer essence of the project among the stakeholders.
Today, we will analyze the stage of collecting requirements using the example of one impersonal project.
eCommerce project inputs
Meet Steve, the Commercial Director in a Lighting Equipment manufacturing company.
The Board of Directors set the task of going online, creating an eCommerce platform for the dealer network and forming a new distribution channel. Steve is an expert in his field, but has not been involved in eCommerce before. And, although the general idea is clear, the prospects are vague. Where to begin?
Unfortunately, Steve did not speak with me and spent a lot of time studying all the basics on his own.
Types of requirements for development of an eCommerce project
A requirement is a set of requests/statements regarding the functionality, attributes, properties, or capabilities of a system.
A simpler version of the definition sounds like “user needs, fixed in the written or verbal form, that the system should fulfill”.
Requirements can be conditionally divided into 2 large groups: Functional and Non-functional.
Let’s analyze the main groups of requirements. We’ll begin with the concepts and continue with an example of how to better formalize them.
Functional requirements
Functional requirements define the activities that the system should be able to perform. The best format for describing functional requirements is User Story, Users Cases, and Wireframes.
At the same time, it is important to first define the tasks and goals of all participants of your future project, or in other words, to formulate roles.
For example: As a warehouse employee, I want to be able to scan the barcode of an item using a scanner connected to a workstation and see detailed information about the item in the warehouse management system.
The example is not ideal, since the user’s motivation is not enough. But it is a good answer to the question why we need detailed information, as quick enumeration of the system attributes is not enough.
Non-functional requirements
Non-functional requirements define the properties that the system should have, or the constraints it should comply with, that are not related to the behavior of the system.
For example, performance, maintainability, extensibility, reliability, operational factors.
Non-functional requirements include requirements like:
- The system should sustain up to 10,000 competing requests without performance degradation.
- Or the interface of the pickup point employee should be simple with a minimum set of functions for easy training of employees.
Great, we have gone through the definitions, we know and will take into account the functional and non-functional requirements at the stage of project preparation.
Read more practical tips on how to collect requirements in our recent article.
Fuzzy vs clear requirements for an eCommerce project
Follow a simple principle to form detailed requirements:
- Independence: any requirement can be considered as a separate project with a specific set of functions, logic, and properties.
- Reality: specify a reference of a really working project.
- Consistency – one requirement should not block another and not violate the logic of the process.
- Necessity – a requirement has value to the product.
Why is this principle good? It will allow the development team to evaluate each requirement on their own. When planning the timeline, you can use iterative development, instead of waiting for a monolith development for a long time.
Read more:
Monolithic vs Microservice Architecture
User requirements formulated. What to send to the development team?
Let’s go back to Steve. He has just formulated the requirements on his own and is preparing to send a request to contractors. He, like a hero of a popular program, need to choose the correct answer:
- ‘I want a marketplace similar to Amazon’
- Form a document of User Requirements consisting of 800 pages to take everything into account
- ‘Make it beautiful, you are the experts!’
- Finalize requirements with all the stakeholders
Why is D correct? When you form requirements independently, the principles of Consistency and Independence are often missed.
Example 1
Returns in the Steeve’s system will be handled exclusively by the accountant. The accountant should indicate the reason for the return and the return amount, and check if the bank completed the refund.
But at the same time, only the pickup point employee and the support service specialist can change the order statuses, and only the support service specialist communicates with the client.
What should the accountant do in this situation? To ask about the reason for returning to the call center.
The solution is simple – to split this requirement and the process itself into two components.
- The support specialist creates/initiates a refund, indicates the reason. The amount to be returned is taken from the cost of the order minus “non-refundable” items, such as paid shipping.
- Then the accountant who has access to the returns with the information already filled in and conducts the return. He or she checks the bank account for the execution of the return and changes the status.
With full automation, of course, we just expect an automatic status change.
Example 2
Please pay attention to answer B: to form a document of user requirements (or specification). Undoubtedly, one of the most important factors is completeness. Higher detail will certainly reduce the risk of missing important details. But here it is important to maintain balance.
Benefits of completing a specification
There are many advantages of a specification. Here are just some of the most critical:
- Elimination of uncertainty – clear instructions, you don’t make a project on the fly
- Clear budget – all tasks for implementation can be estimated, and you know the total cost of the project
Disadvantages are also present:
- Time to prepare a specification – it takes one month on average
- Limitations due to detail level. There 3 levels of project implementation granularity:
- Coordination, a level that is enough for discussion with the project managers
- Analytical, for discussion at the level of project stakeholders
- Executable – for setting a task to the developer.
More about writing specifications can be found in this article.
Speaking about elimination of uncertainty – is there any certainty at the start?
In my experience, I have almost never seen 100% compliance with the planned and final. And this is only for one reason – the market is alive.
Dmitry
While Steve is writing the user requirements for 3 months, the situation has changed.
You can’t win the race against time, but you can be faster than your competitors.
Conclusion
By following our tips and adapting them to your project, you can efficiently capture and communicate project requirements to the developer. Thus, you will save your time, clearly define for yourself what you expect from the project in the end, and as a result, you will get the very project that you planned. When choosing a contractor to fulfill your requirements, be guided by experience and guarantees of the quality of work. Simtech Development is a top CS-Cart developer with over 16 years of experience and an arsenal of +130 projects around the world.