How to Develop Software Requirements for eCommerce Projects
By Michael Serra, QA Automation Engineer
How to Develop Software Requirements for eCommerce Projects:
A primer on effective communication between clients and digital agencies
How often do we all talk about being “on the same page?” While this may seem like a cliche, there’s at least one time when it really means what it says – when you’re developing software requirements for an eCommerce store.
Whether between clients and agencies, designers and user-experience teams, or, of course, website implementation teams, accurately defining the requirements of a project is key to its success. So, in this article, I’d like to give a brief overview of the mutual understandings and specification documents used to produce an eCommerce site. Along the way, I’ll illustrate some potential communication challenges that must be overcome to get everyone involved truly “on the same page.”
Defining What ‘Requirements’ Means
In a formal sense, ‘requirements’ are narrowly regarded as a set of logical properties and behaviors that programmers are expected to implement in code. But in the broader business context – especially for digital agencies – the concept must be viewed more broadly. At Lyons Consulting Group, we define a requirement as:
Any aspect, feature, or behavior of a software product, including its visual appearance, user experience, performance, and all business goals the client expects it to fulfill.
This perspective has been essential to our success at LYONSCG as a holistic practice: our ‘requirements’ go beyond technical concerns to include the broader set of services on which our client partnerships are built.
How are Software Requirements Developed between Client and Agency?
At LYONSCG, our process usually begins with a period of discovery in which we work with clients to understand the needs of their business and the goals they aim to achieve via eCommerce. The outcome of this process is a business requirements document or BRD. Although this is a non-technical document, in many ways it is the project’s most important specification because it declares the ultimate objectives of the partnership.
During this period of discovery, one essential practice is a careful review of client expectations coming from any existing (legacy) system they currently use. What the client has experienced from their software – both good and bad – will heavily influence what they want and what they tacitly expect from a new design and platform.
A simple but effective exercise to mitigate this risk is to have all members of the team, from user experience (UX) through design and coding, explore the client’s legacy system and exercise its features before the design of the new site is finalized.
How is a New eCommerce Site’s Visual Design Developed?
In the next step of the process, the BRD drives collaboration between the client and our user-experience (UX), digital marketing, and creative design experts. From these discussions, two sets of documents important to site implementation emerge:
- Wireframes, which describe the technical behavior of the site’s user interface.
- Creative comps, which illustrate the site’s exact visual appearance.
Before any site implementation begins, the client and agency both review and formally approve these sets of documents. However, the specification process doesn’t often end there! Throughout site implementation, continuous communication with clients is essential to uncover potential miscommunication or to meet newly-discovered client needs.
Recommendations for a Successful Project Implementation
Based on our extensive experience designing and building hundreds of eCommerce sites, LYONSCG offers the following advice both to our clients and our internal teams:
1. Ensure that business requirements are understood by every department involved in the implementation. The importance here is that when gaps or questions arise about a creative comp, a user-experience feature, or software logic, an understanding of the business rationale behind the specification documents can fill in the missing information. Maintaining a bird’s-eye view of a project’s ultimate goals makes it harder for one department to misinterpret the specifications provided by another.
2. Keep a clean separation of concerns between wireframes and creative comps. It’s easy for ambiguities to appear between these two sets of documents because wireframes use visual aids to illustrate the UX functionality they describe. If comps depict or imply functionality that isn’t explicitly described in the wireframes – or, worse, that contradicts the specification in the wireframes – a delayed or incoherent implementation may result.
The rule of thumb here is to specify only program functionality in wireframes, and only style and appearance in creative comps; both client and agency should also perform a thorough side-by-side comparison of the two documents before starting implementation.
Last but not least, the client should be apprised not to infer any functionality from creative comps – this is especially true if the comps are produced by a third party; and if the client offers comps which disagree with wireframes, it’s a sign that implementation should pause for discussion and clarification of expectations.
3. Use consistent technical terminology. In the case of web development, we’re lucky to have a set of basic terms – the HTML tag names – to keep things clear. But not all components of user interface design are so easily described. A classic example is the misuse of the word “modal” as a noun. From a programmer’s point of view, modal is an adjective – it applies to layered UI elements which prevent interaction with the layers below them. So when ‘modal’ is used as a noun, it leaves the implementor unsure of exactly what’s required – it could be anything from a small dialog to a full-page window. Similar confusion occurs with words like “drop-down”. In general, the more parallel the UX and programming teams can keep their terminology, the better.
4. Carefully scrutinize legacy client sites. As mentioned briefly above, when clients have existing eCommerce sites – especially long-standing or complex ones – their intimate familiarity with their existing system can easily introduce undocumented assumptions into the requirements discovery process. Because of this, it’s essential for any features taken from the legacy system to be scrutinized in its context. Subtle changes to the new site’s design can have radical implications for the functionality of these legacy features, and if trouble arises it’s often an unpleasant surprise for clients who naturally expect the system they already have to be easy to emulate.
In conclusion, the software industry has always experienced challenges in formulating an effective project specification process. The inherent problem is obvious: there’s a huge gap between the verbal and visual languages used by people, and the extremely formal languages required to program computers. At a digital agency, the challenge is further complicated by the many specialists involved – LYONSCG often incorporates creative design, user experience, digital marketing, search engine optimization, code implementation, site hosting, and other services into the scope of a single client partnership. Our experience with a wide variety of clients and projects has taught us unique insights into the production of high-quality software requirements, and we believe that putting these lessons into practice has helped us become the industry leader in site quality and client satisfaction that we are today.
Want to learn more? Contact us.
