Before compiling a technical assignment for the development of an IT product, one should understand what tasks the eCommerce site is intended to solve. To form this understanding, you need to take into account the interests of the target audience and those who will work with the site within the company. That is “gather functional and business requirements”. It helps accurately estimate the budget and the time to execute your task, and developers will not have to redo their job. In this article, we will tell you what functional and business requirements are, how to collect them right and what is the best way to convey them to the developer.
What are business requirements
Business requirements are high-level requirements, your ultimate goals. These are common tasks that your site should solve. Business requirements should be clear to the head of the company, who may not be familiar with the technical intricacies of web development.
Business requirements include:
- Information about the company: field of activity, product, customer profile, and competitive advantages.
- Target audience data. Who will visit the site: gender, age, region of residence, habits and hobbies. You also need to understand why people come to the site. For example, to buy goods, find out the cost of a design project, or read the news.
- Competitor analysis.
- Purpose of starting the project. For example, to enter a new market, become a monopoly in a niche, move your business online.
- Specific goal. For example, to provide delivery to Israel. Increase turnover (in figures). Accelerate the processing of orders through automating the managers’ routine.
- Planned metrics. Double the traffic in the first year of the project launch. Increase traffic conversion rate from 0.8% to 1.1%. Triple the number of vendors. Raise direct online sales by 30% in six months.
- User requirements. What task the user is supposed to solve on the site. If the user is the site visitor, it might be ‘to buy shampoo’. Arrange delivery to another country if the user is another company. Increase earnings if the user is a vendor. To have access to orders only when the user is a sales manager and so on.
How do business requirements affect the final product?
Often, business requirements affect the way a product is marketed. For example:
- To promote the marketplace with the vendors, the marketplace owner can offer them to stay working in their systems and integrate these systems into the marketplace. In this case, vendors are released from the necessity to learn a new interface. The owner has all the necessary data sent to his or her platform thanks to integration.
- Under the terms of a franchise, only one seller / representative can be assigned to a certain location and process orders from customers of this region. The sale of goods in this territory by other representatives of the brand is prohibited under the terms of the contract. The final product of development will be geolocation of a customer to sort products and display the available stock for this specific region, and association of the customer with the seller for further orders.
- The owner of a catalog site (where you can view products, but not buy them) wants to create an online store based on it without switching to a new platform. In this regard, the requirement is to implement the checkout functionality from the CS-Cart platform, but in such a way that it looks “seamless” for the customer, as if he did not leave the existing site. The final product will be the integration of single sign-on technology – SSO – in which the user moves from one system to another without re-authentication.
Why is it necessary to clearly formulate business requirements?
Clearly articulating business requirements is important because it:
- Allows you to manage expectations: the developer learns about expectations and can offer the best solution
- Is possible to more accurately estimate the amount of work
- Saves your and developer’s time on collecting requirements
- Help in structuring information: you understand what’s required while identifying requirements
For example, one of our customers came with a request to create an all-inclusive eCommerce platform. It was planned to connect banking systems, legal and educational organizations to the platform as vendors. Six areas of work with clients have been identified. However, in the process of identifying requirements for the platform, it turned out that the customer had not yet clearly defined the final product for himself. So in the client brief, we asked what the product and what the CJM (customer journey) would be.
Below is a brief to clarify requirements:
- Describe your product/service. What will be the product? What are its features? How will its price be calculated?
- User roles (administrator, seller, and buyer): what actions can each of them perform? Are there any dependencies/limitations?
- CJM (customer journey through the site): what will be the process of purchasing your product? What appropriate actions will the seller/administrator need to take?
- User registration: what data do users need to provide to register?
- What will the personal account (profile) of the customer look like for using the service? What actions can he or she perform?
- Will integration with third-party systems be required? What systems?
Then, at each stage of development, a more granulated collection of requirements is needed to structure the information both for the website owner and the developer.
So, business requirements are the general tasks that the site should solve. Once the business requirements are clarified, the collection of functional requirements begins.
What are functional requirements?
Functional requirements are a statement of the task to the developer. They describe everything that the system should do. These are the functions performed by the system within the framework of a specific task.
Examples of functional requirements:
- Vendor is registered in the system: the system logs the vendor data as an input and displays it as an output on the page of all vendors
- Assigning a unique order number: The system processes orders for orders. An order is placed, the system assigns a number to it and outputs a list of orders
- Delivery calculation: the API system requests data from the delivery service and displays the calculated delivery cost on the order page
- Tax calculation: the system automatically calculates the tax for the selected US state using the functionality of the TaxJar service
- Mobile wallet support: in MENA (Middle East and North Africa) countries, the system accepts payments from a mobile phone
Non functional requirements
In addition to functional requirements, there are also non-functional ones. These are the attributes of the site that are needed for its stable operation, not related to the main functionality. They can also be rules or restrictions that apply to the entire system or product.
There are a lot of non-functional requirements. Here are some examples:
- UX/UI Design. Add an additional checkout button. When going to the product page, the user sees all variations of the product.
- Use of JS code
- Use of a specific repository
- Use of specific libraries.
- Setting up CI/CD processes. In simple words, CI / CD (Continuous Integration, Continuous Delivery) is a technology for automating testing and delivering code to stakeholders (developers, analysts, QA testers, and end users.).
- Add-on adaptation. You can choose ready-made solutions on the marketplace and use them to quickly close some functional requirements. For example, using the Google Analytics Enhanced Ecommerce add-on, you monitor purchase events on the site directly in the platform admin panel. Sometimes, one may require to modify an add-on to fit the needs of a particular project.
- Content. Add links to legal documents to product pages. Such a requirement is often voiced by the owners of German marketplaces.
- Site performance. The site should sustain a concurrent load of 1,000 people online.
Who collects functional and business requirements?
Initial requirements are collected by the sales manager. This process can also involve:
- Third party agency
- In-house analyst
- Our team within the “Design” service
Even if you come with ready-made requirements, oftentimes, they need to be adapted to consider the features of the CS-Cart platform. That is, we superimpose your wishes on the capabilities of the CS-Cart platform and advise the best way to implement it.
How are requirements collected?
Requirements are collected through interviews, correspondence, through special systems like Notion, Trello and others. The format is the following:
- You provide general requirements for the product, or a briefing is carried out to compile the MVP.
- If the request is described clearly and specifically, then the manager discusses the requirements with a technical expert.
- A rough estimate of the implementation is given.
- If clarification is needed, the missing information will have to be voiced additionally. The time and cost of the work is being reassessed.
Who is involved in the collection of requirements?
Whom to involve from the company for an interview depends on the needs of the project. Think about the interests of stakeholders within the company? For example, to collect requirements, you can invite:
- Vendors: those who will work with the system if the project wants to take into account the interests of sellers (in the marketplace).
- Accounting (to understand what reports are needed or how to make payments).
- Legal department (whether there are any legal restrictions that need to be taken into account when creating an online store).
- Marketing (for example, for promotions)
- Vendor attraction department (for marketplaces).
- IT department (if available, as it will have to maintain the finished system after the delivery of modification)
- Security specialists.
- Third-Party Experts.
Auxiliary materials provided to speed up collection of requirements
Additional materials help the performer to better understand the decision-making process in the company and organize the work in the most effective way. Such materials include:
- Competitor analysis
- Examples of competitors and implementation of the desired functionality
- Examples of companies you want to be like
- Description of the target audience (helps to shape the design of the store, taking into account the age and preferences of users, B2B or B2C functionality)
- Design layouts
- Development plans (so that you can lay the scaling of the project). For example, site load, project monetization methods, ROI plans, etc.
- List of roles of project participants (who is the end customer or who makes the decision). Decision-making scheme (for better alignment of work).
- User-cases (description of scenarios in a certain situation, for example, when the user registers, the following happens.
What other documents might be useful
In order for the specification to be complete, it is desirable to provide the following documents:
- Flowchart describing business processes and functionality
- Architecture flowchart
- Project description document (a general description of what will be presented on the admin, vendor and user panels)
- Road map
What mistakes do customers make when collecting information?
- Choosing an initially inappropriate third-party service. This happens when you ask to connect a service without explaining the purpose. After integrating such a service, it turns out that it does not have additional functionality that the store needs. Therefore, it is so important to provide a process description scheme and the purpose of the modification to the developer. The experience of a developer can help you choose the best integration solution that fits your store’s processes and goals.
- Choosing the wrong platform. One selects a platform without understanding its features. For example, the business is conducted according to the marketplace model (Multi-Vendor), but a single-user online store (CS-Cart) is purchased. Before buying a license, it is better to contact the contractor and describe the business model and business processes of the company. So, the developer will be able to suggest which platform option is best suited.
- A malformed request. For example, one asks to fix the code to optimize the site when it is necessary to improve SEO performance. Here, a clear description of the problem and the desired result will help. The contractor will be able to choose a comprehensive solution that helps to optimally achieve the goal.
How detailed should the requirements be?
It is crucial to strike a balance between detail and redundancy. If you go into too much detail, the specification will be overloaded, and the developer will need a lot of time to study it. At the same time, when the requirements are too granulated, it is better to communicate the business goal and rough vision to the contractor. So the developer can better choose the appropriate implementation option.
- An example of a non-detailed requirement: The registration form should be convenient and simple.
- How to: The registration form should contain three fields: name and email. In addition, the user should be able to register through social networks.
- Example of a non-detailed requirement: The page should load quickly.
- How to: Website load time should be 3 seconds. It should keep operability with attendance of 100 thousand people per day.
Recommendations to writing the requirements
It is desirable to write as simply as possible with an unambiguous wording (customer, vendor, site administrator) and the result. The best format is the user-cases. In this case, the functional requirements for the system are presented as a set of functions combined by context. For example, the Use Case “Schedule a visit to the clinic” might include the following features:
- View the history of visits (data on past and planned visits);
- Add a new visit;
- Select visit;
- View details (date, time, place, doctor) of the visit;
- Change the details of a future visit;
- Delete future visit.
If business analyst is you:
You can use the following methods to gather requirements:
- Questioning. The most famous example might be the “Brief for the development of the site” – a questionnaire containing a list of basic requirements and information about the future site.
- Interview. This method is used mainly to obtain information on a specific issue and to clarify the requirements.
- Brainstorm. Participants generate many ideas – solutions – and develop each other’s ideas.
- Asking for direct task executor
It is critical to collect functional and business requirements before forming a specification for the development of a site. This will save your budget and efforts, and eliminate misunderstandings with the developer.
The more specific the requirements are, the more likely it is to create a site that will solve all the tasks. Specific functional requirements should always be supplemented by generalized business requirements. This will allow you to choose the best way to solve the problem.
You should take part in the collection of requirements, since you better understand all the specifics of the business. But if the company is small, it is worth outsourcing specialists to the project or entrusting the collection of requirements to a development team. Whichever path you choose, take an active and direct part in all stages. So you guarantee that all the features of the business will be taken into account.
In our company there is a service called “Architecture design”. Our specialists will collect the requirements themselves, adapt them to the chosen platform, and provide you with all the necessary materials to understand the project. We guarantee the quality of our work and post-warranty service for 100 days.