Skip to main content

Get Started with the Technical Project Documentation

Learning Objectives

After completing this unit, you’ll be able to:

  • Explain the difference between functional and nonfunctional requirements.
  • List the nonfunctional requirements.
  • List the settings you need to document.
  • List what’s in a technical specification.
  • Explain why it’s important to document the merchant’s services.

Get Started

B2C Commerce merchants—companies that sell products online—hire technical architects as consultants or through a partner organization to help implement a storefront. As a B2C Commerce technical architect, you’re a key member of the storefront implementation team that takes a site from sign-on to live. While your team includes various other roles, your focus is on the technical aspects of the implementation. For more about the Commerce Cloud architect role, see the Resources section in this unit. 

In this module, you learn how to document the technical requirements for a B2C Commerce implementation. 

To get started, it helps to understand the general project workflow for an implementation.

  • Discovery: Collect merchant data.
  • Design: Document requirements, design, settings, and so on.
  • Build: Build the application.
  • Integrate and customize: Bring in the third parties.
  • Test: Test, monitor, and troubleshoot the application.
  • Launch: Go live

The general project workflow is discovery, design and build, integrate and customize, test and launch.

Discover and Design

Documentation is important at all project phases, but the bulk of requirements identification happens during discovery and design. You use a discovery approach to identify and document the merchant’s requirements so that you can create a solid design. See the Salesforce B2C Commerce Client Analysis module for details on the discovery phase.

In the design phase, you design both functional and nonfunctional requirements.

Functional and Nonfunctional Requirements

Functional requirements describe site behavior, while nonfunctional requirements describe general and technical characteristics. 

Functional Requirements

Nonfunctional Requirements

  • Storefront functionality by page
  • User interfaces
  • Standard functionality vs customizations
  • Integrations specification
  • Security
  • Performance
  • Data validation
  • Testability
  • Maintainability
  • Disaster recovery
  • Localization

This module focuses on documenting the non-functional requirements. See the Project Documentation for Salesforce B2C Commerce Functional Architects module for more details on functional requirements. 

Main Specification Documents

These are the main specification documents you help create and work with.

Technical Specification

Functional Specification

  • Project overview
  • Site model and data setup
  • Architecture and architecture diagram
  • Data flows analysis
  • Integration and data feeds
  • Interface specifications and schedules
  • Data model and data mapping
  • General non-functional considerations, such as security, performance, and disaster recovery
  • User interfaces
  • Functionalities by page
  • Gap analysis with the reference application of choice
  • Nonfunctional considerations by page, such as:
    • Validation framework
    • Localization
    • Testability
    • Usability
    • SEO

Intro to the Technical Specification

The technical specification contains the precise technical details that are critical for implementing a B2C Commerce storefront. Your job as a B2C Commerce technical architect is to include as much detail as possible to help the implementation team know exactly what they are supposed to do.

The technical specification document (TSD) helps bridge the information gap between the development team and the technical support team.You take a deeper look at this document in the next unit. For now, let’s look at some of the settings and configurations you need to include in this document. The attention you pay to details such as configuring data retention in Business Manager and adding services to the B2C Commerce Web Services framework will keep systems and processes running smoothly.

Project Requirements

Let’s get started by looking at example project requirements for a B2C Commerce storefront implementation. 

Area

Details

Content

  • Product, category, and search pages
  • Content asset based or Page Designer content
  • Store locator (if used)

My Account for shopper login and credentials

  • Profile page, addresses, and payment instruments
  • Order management system (OMS) integration for order history
  • Loyalty program integration

Checkout

  • Basket, product line items (PLIs), shipment, payment information, order
  • Live inventory checks (if used), address verification

Back-office

  • Back-end integrations such as cross-cloud integrations
  • Customer service functionality

Settings and Configurations

Here are some of the settings and configurations you need to document.

Site Configuration

Each B2C Commerce instance contains code and data, and both can be used in one or more sites. Because the code and data is logically divided, it’s easy to create multiple sites, each able to support a different locale. Additionally you can surface each site on one or more URL hosts/domains. Use a table like this to document the site configurations.

Site

Currency

Locale

Domain 









Data Retention

Document data retention settings.

Data type

Data purge policy

Orders


Payment


Customer Profile


For details, take a look at the Holiday Season Readiness with Salesforce B2C Commerce Trailhead module, the “Cleanup Storefront Data” unit.

Hostname Aliases and Redirects

Configure hostname aliases and redirects per best practice standards. List host name aliases and provide a sample redirect setup.

API Quota

Document potential quota issues, for example, too many HTTPClient calls during an order submit call.

The Web Services Framework: Configured Services

Managing all the merchant’s web services in one place via the Web Services framework is important because it lets merchants manage calls to unavailable web services, cap the number of calls to a web service, and analyze web service performance, and more.

Document each service in a table like this to make sure all services are covered. You’ll provide more details for each service in the Interface Specification Document (ISD), a separate document that we explore in unit 4 of this module.

Service

Type

Description







For details on using the Web Services framework, see the Holiday Season Readiness with Salesforce B2C Commerce Trailhead module. 

WebDAV and SFTP

Document the transfer server interfaces like SFTP and WebDav folder structure. These are used for asynchronous integrations between B2C Commerce and various vendors and systems. Use a naming convention to distinguish between sites, and between production and test environments.

SFTP

Details

Login


Home directory


Directory structure


Next Steps

In this unit, you learned about functional and non-functional project requirements and the documents you need to create. One of those documents is the technical specification. You explored some of the settings and configurations you need to document for a successful implementation. Next, take a deeper dive into the technical specification.

Resources

Keep learning for
free!
Sign up for an account to continue.
What’s in it for you?
  • Get personalized recommendations for your career goals
  • Practice your skills with hands-on challenges and quizzes
  • Track and share your progress with employers
  • Connect to mentorship and career opportunities