Document Requirements and Build the Storefront
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the importance of the Functional Specification Document.
- Describe the contents of a Technical Specification Document.
- Understand the importance of scope gap analysis.
Document the Requirements
Your team has traveled far and completed many important tasks. It’s time to journey even deeper into the details. Our next stop is Requirementsville. It’s an unusual place—everything is labeled with an id and a description of how it functions. It puts your team in the mood to document the requirements.
Functional Design Specification
A functional specification document (FSD) answers the question, “What does the site do?” It explains site behavior from the user’s perspective. NTO’s storefront is a substantial site. Explaining every behavior is an equally substantial task. Luckily, some of that work is done for you. Do you recall how your team only created design wireframes for customizations because wireframes for standard features already exist in the SFRA? You get a similar head start with the FSD. Your team only writes functional specifications for behavior that deviates from what’s already covered in the SFRA. That’s a huge time-saver.
Mindy, your functional architect, guides the team as they write specifications for all custom functionality. She also has them document where the NTO site intentionally omits SFRA functionality. You stop by and have a laugh when you see that the team has even labeled Mindy. The description? Keeps the fun in functional specs.
Technical Design Specification
The technical specification document (TSD) is the sister document to the FSD. It answers the question, “How does the site do what it does?” It contains the precise technical details for how to build the functionality described in the FSD. The TSD is a high-potency document. Your development team uses the TSD to build the storefront. The technical support team uses it to understand the storefront implementation details.
There’s a train-car load of information to capture in the TSD. As an experienced project manager, you already know much of what to include. Here, we highlight the areas that are more likely to be missed or underestimated in B2C Commerce implementations.
Data Mapping
NTO has a huge product catalog stored in a proprietary database. You need a plan to transform their data into a data model that the B2C Commerce–powered website understands.
One of your developers is a database guru. Alex, your technical solution designer, gives the developer the SFRA list of predefined data fields to use as the destination fields for NTO’s data. The developer completes a data-mapping plan to document how NTO’s data fields, types, and values map to the SFRA fields.
He repeats the mapping exercise for all key data files:
- Catalog
- Price books
- Inventory
- Order export
As he maps the customer’s data to the SFRA data model, he takes special note of fields that don’t neatly map to SFRA destinations. He also documents any other unusual data requirements. Alex reviews the data map to identify possible impacts and documents any special data-handling requirements in the TSD.
System Integration
The system integration plan maps out how and when the various external systems interact with NTO’s new site. An average B2C Commerce site implementation includes four third-party integrations. Alex carefully devotes a lengthy section of the TSD to system integration.
Search Engine Optimization and Analytics
Search engine optimization (SEO) is an art form in itself. It’s common for your customers to collaborate with another Salesforce partner for SEO, and NTO has. It’s your responsibility to coordinate with NTO’s SEO partner to capture SEO specifications.
If the project includes an existing site migration, add a specification to use 301 redirects that send both users and search engines to the new URL. Designate how the redirects are determined and completed.
B2C Commerce includes web analytics support, but most customers also use another system. Identify which system NTO chooses and list it in the TSD.
Load Testing SOW
Salesforce works with a third party for load testing. To conduct load testing, either you or your customer must have an SOW or contract with the third party. On this project, NTO contracts directly with them. You introduce NTO’s project manager to the third party so they can sort out the load testing details.
Accessibility
The W3C’s Web Content Accessibility Guidelines (WCAG) explain how to make web content more accessible to people with disabilities. WCAG is a technical standard. In some countries, WCAG conformance is mandatory. Mindy checks the conformance requirements by country to see which apply to NTO’s site. She confirms that the site design meets or exceeds country-specific requirements.
Scope Gap Analysis
At this point, your team has looked in every nook and cranny for detailed requirements and accounted for all of them in the FSD and TSD. It’s another good time to look for scope creep. Review your SOW and HLD. Any changes since those two documents were written? That’s your scope gap. Create change orders and update your project plan accordingly.
SRA Specification Review
The NTO project includes SRA specification reviews. The Salesforce B2C Commerce Professional Services team steps in to review your project specification documents and site design. You’re required to pass the specification review milestone during the requirements phase. And your team has to close out any issues that come up during the review. In your project plan, you wisely budgeted time for the whole team to prepare for the reviews and to resolve issues. As a result, the review milestone passes uneventfully.
Before your team builds the storefront, stamp the FSD and TSD documents with a date and version number. To prevent confusion about what the official requirements are, you have NTO sign-off on the requirements and any change orders. If you develop iteratively, you do this iteratively too. At the same time, you remind NTO to prepare test and production data. It’s NTO’s responsibility to provide sample product data and production-ready data for use during build, test, and launch. Every last requirement is accounted for and reviewed. It’s build time! Your team heads back to the train to start development.
Build the Storefront
The bits and bytes are flying as the development team settles in to build the storefront. Every partner has their own way of handling implementations—Waterfall, Agile, or a hybrid development method. At Salesforce, we’re fond of an adaptive approach that utilizes elements of both Waterfall and Agile methodologies. For B2C Commerce projects, adaptive sprints typically last 2–3 weeks. We suggest adopting this methodology to quickly produce working software and ensure that deliverables stay on track. Independent of any specific development methodology, you use your own code repository management and development best practices.
Requirements and Build Deliverables
- FSD
- TSD
- SFRA annotated wireframes
- Data map
- Updated project plan
- Sample product data (customer supplied)
- Production-ready data (customer supplied)
- Test plan
- Load testing SOW
Resources
- External: Q3C Web Content Accessibility Guidelines
- External: Manifesto for Agile Software Development
- Trailhead: Salesforce B2C Commerce Client Analysis
- Trailhead: Project Documentation for Salesforce B2C Commerce Functional Architects