I have been writing business requirements for web-based portal applications for years now, but writing my first requirements for an AEM implementation was a learning experience.
The first thing I would suggest is that any Business Analyst who is writing requirements for an AEM implementation should understand how AEM works, including its features out of the box and the role of components, templates, workflows and the other features that make AEM a powerful tool with great potential.
Learning about AEM helped me provide better guidance to clients and to talk AEM jargon with my dev teams. Beyond understanding the platform, there are several other things you can do while gathering requirements for AEM that will help ensure better final results.
(BYBA) Bring your Business Analyst from Day 1
Bring your Business Analyst in on day 1 of your project. Your Business Analyst will serve as your guide; they should be someone who understands your business and who has a good understanding of the potential of AEM.
I have worked with clients who were implementing AEM for the first time and were not aware of the full potential AEM.
That lack of knowledge about the platform was causing them to recreate their legacy CMS using AEM. Working with a team of AEM Architects and an AEM Business Analyst helps our clients not repeat history, instead helping them to move toward a better future.
As a Business Analyst, I always ask clients what they want to achieve with a specific functionality; they might have an idea of how they would like it implemented, but real question is what do they want?
Know your site from a 30,000 foot view
Understanding your high level requirements before you begin the design process will help you keep your project on time and in budget.
For example, you should know:
- What workflows to optimize, prior to implementing AEM.
- Which user roles and permissions you’ll need to set up.
- Is this a multi-language site? If so, how is translation handled?
- Will you have any tracking/analytics?
- Is the site responsive with a mobile-first approach?
- What browsers will be supported?
- Who are the average site users? What do you know about them?
- How often is search used and how important is Search Engine Optimization to your company?
Get those functional specs as the design develops
Writing up functional specs during the wireframe/mockup process saves a lot of time and avoids any confusion as to what is expected out of the site. You’ll want to define any transitions you’ll need, the global elements that will apply throughout the site, and the types of templates you’ll need.
Any transitions needed within the site should be part of the final designs. If you are building a responsive site with mobile first in mind, make sure you have wireframes for all breakpoints and identify functionality for each breakpoint.
Identify your global elements that are consistent across the site. These global elements can be inherited using parsys with a template.
Identifying what’s different on each page of site will help identify templates needed for your site. Think of a template as a canvas that you can draw on; depending on your needs, a template could be an empty canvas or a template could be like a coloring book, where you have predefined outlines and all you have to do is add color to it.
Don’t forget your content authors
When writing requirements we spend too much time on end user experience, identifying minute details of how a site visitor will be interacting with the site on various platforms and devices, that we forget the most important user in AEM—I am talking about the content author.
Content author requirements are as important as the site user experience, so always keep the author in mind when documenting requirements.
One of the main reasons any client switches from a legacy CMS to AEM is the lack of flexibility and frustration when authoring, so ensure you discuss author experience when talking about components, templates and other areas within AEM.