Technical Specification for 1С-Bitrix Website Development

Imagine you're launching an online store on 1С-Bitrix. A catalog of 15,000 products, integration with 1С, a B2B cabinet for dealers. The developer asks: 'how do we filter by stock?' – and it turns out that nowhere is it specified that prices should be individual for each dealer group. Result: reworking the filter and personal account adds 40% to the budget. According to our statistics, 80% of performance issues arise from unclear infoblock descriptions, and revisions during development cost 3-5 times more than fixing the specification. That's why we create a technical specification that captures all requirements before development starts. Order a technical specification – we'll prepare a document that saves you up to 50% of the budget and eliminates misunderstandings between you and the developer.

What sections must be in a Technical Specification for Bitrix?

A TS for a Bitrix project differs from a TS for a generic website. In addition to standard sections (goals, audience, functional requirements), specific sections are needed.

Edition and Licensing

Specify the Bitrix edition (Start, Standard, Small Business, Business, Enterprise) and justification. For an online store, the minimum is Small Business (catalog module, SKUs, one price list). If you need an extended catalog with multiple price types, discount rules (sale.discount), stock aggregation across warehouses – Business or Enterprise.

Infoblock Structure

List all infoblocks with property types. This is where a decision is made that later cannot be changed painlessly: property type 'String' vs 'Directory' (HL-block). For each infoblock, a table:

Integrations

Exchange with 1С is described separately: synchronization direction (two-way or only export from 1С), frequency, what is synchronized (stock, prices, images, properties). The mistake is to write simply 'integration with 1С'. Specify: which 1С configuration, standard exchange via CommerceML or custom integration via API, field mapping.

Performance

SLA for page response time: catalog section ≤ N seconds with M concurrent users. This is the only way to formalize performance requirements – without this section, speed complaints cannot be raised.

How to avoid mistakes when designing a TS?

A structured TS reduces rework by 3-5 times compared to verbal agreements. Formal TS is more effective: rework occurs in only 10% of projects vs 70% with verbal agreements, saving 30–50% of the budget. We recommend including user scenarios and technical requirements that are often missed.

Designing User Scenarios

A TS without scenarios describes the system but not how people work. For a Bitrix project, important scenarios:

• Checkout: number of steps, authorization, delivery/payment methods, cart behavior for unauthenticated users.
• Personal account: order history from b_sale_order, statuses, ability to reorder.
• Administrative scenario: how a manager adds a product, edits price, processes an order.

Each scenario is described sequentially with references to Bitrix components or marked as 'custom development'.

Typical Omissions in a TS

• User roles and permissions: Bitrix uses groups and permission system for infoblocks, sections, components. For a B2B cabinet or dealer section, the access matrix must be in the TS.
• SEO technical requirements: SEF URLs, meta tags, robots.txt, sitemap.xml – configured via the seo module. Without explicit requirements, defaults are used.
• Multilingual: for multiple languages, specify the structure of language sites in one kernel, content mapping, locale for dates and currencies.

Why does the budget grow without a TS?

Case: a wholesale supplier wanted 'a catalog with filter and personal account for dealers'. A 2-page TS written within the client's team. After launch, it turned out:

• Dealers needed individual prices (three price types per group), but the developer implemented a single price list.
• The filter did not account for stock – products with zero stock appeared in results.
• The personal account only showed orders placed via the site, but dealers expected history from 1С.

Rework took 3 months with an original development budget of 6 weeks. If requirements had been formalized in a TS before work started, the scope and cost would have been estimated correctly. A formal TS is 3-5 times more effective than verbal agreements: rework occurs in only 10% of projects instead of 70%.

How we create a TS: step-by-step process

1. Client interview: identify business processes, users, integrations.
2. Analysis of existing systems (1С, CRM, warehouse).
3. Design infoblock structure and properties.
4. Describe user scenarios for all roles.
5. Formulate functional requirements linked to Bitrix components and modules.
6. Define non-functional requirements: performance, security, scalability.
7. Prototype key screens (wireframes).
8. Review and finalize the document.

Volume of a TS for a typical online store: 40–80 pages. Preparation time: from 2 weeks for a small project to 6–8 weeks for a complex multi-functional portal with several integrations.

What's included in the work

A properly prepared technical specification guarantees a transparent budget and predictable results. Our 10+ years of experience in Bitrix development ensures the quality of documentation. Additional information can be found in relevant articles on Wikipedia and Wikipedia (1С-Bitrix).

Get a consultation and order a technical specification – we'll help prepare a ТЗ for your project and avoid typical mistakes.