2. 1. Mapping requirements

When analyzing the functional requirements, we recommend the following approach for mapping requirements to features and functionality in Kentico. Doing this up front will give you the benefit of having a better idea of the time and resources necessary. Proper research and planning lays the groundwork for realistic goals so that you avoid the panic and delays that come from setting un-achievable goals.

Get familiar with built-in functionality

Selecting the right Kentico functionality for any given requirement requires you to be familiar with what Kentico offers. As with anything, you will become more familiar with Kentico functionality and how to use it over time, but where should you start? Thankfully, there are many resources available to you. We recommend starting with the below:

Evaluate built-in functionality

Once you narrow it down to a feature you think is suitable for your purpose, it is a good idea to evaluate it more thoroughly through a proof of concept. Doing a proof of concept validates whether or not all the functional requirements can be achieved.
If you find that the selected feature meets most but not all of your functional requirements, consider whether you can extend the feature to meet all requirements.

Extend built-in functionality

If you find that you need to extend Kentico to meet some functional requirement, you need to do three things:
  1. Make sure that you've checked the resources mentioned at the beginning of this section for other features that might accomplish what you need to do. This avoids creating a solution to an already solved problem.
  2. Research the available extensibility options of built-in functionality, being conscious of customization best practices in Kentico documentation.
  3. Compare extending Kentico functionality versus building something completely custom. When doing the comparison, consider the viability of one versus the other with regard to the effort (in time and cost), the ease of use from a business or other end user's perspective, and the technical complexity.

Build custom functionality

If you find that there is no suitable Kentico feature that meets your needs, or you determine that extending Kentico is not a viable option, do the following:

  • Architect the solution with low maintenance in mind by using as much built-in functionality as possible.
  • Design the solution to be extensible and scalable for the future.
  • Investigate how other built-in functionality influences the solution (e.g., content staging, web farm, workflow).
  • Scenario: Handling market-based pricing

    A client wants to specify different product prices for different markets (e.g., different geographic regions). The partner developing the site knew from their training and the documentation that the built-in shopping cart price calculation process only allows for one product price. Therefore, they knew that they needed to either extend the system or consider another solution.

    After doing some research, the partner found in the customizing product prices documentation that they could customize the SKUInfoProvider to change the pricing logic. Further research revealed e-commerce customization best practices article discussing this exact problem and a possible solution.

    As the customization is minimal, fulfills our requirements, and is extensible for new markets in the future, this approach was selected over building something completely from scratch.
  • Scenario: Synchronizing product information

    A client needs to update the product stock and price information in Kentico from an external system that offers a web service for this data. The partner knew that there is no direct support in Kentico to handle this integration without writing code. The customization option they found most suitable was the scheduled task feature in Kentico.

    They built a custom scheduled task that called the external system's web service to get data, and used the Kentico API to update the products in Kentico. By using the Kentico API, they knew that the system would ensure that the built-in features, like staging and web farms, would work properly.

    The external system provided a way to request only changes since a certain date and time, so the partner used this to request only products which were modified after the last successful product import. This ensured that the solution was scalable when the number of products grew.