Intro to Requirements Gathering

So often, those of us in the digital agency world tend to focus on our individual roles when it comes to project planning, mostly to ensure that projects are being tackled by well-rounded teams. Every project needs management, creative, development, quality assurance, and marketing at key stages, but it’s important not to lose sight of how all of those roles affect each other throughout the entire project lifecycle.

Even though requirements gathering is a job often assigned to either the project manager or the business analyst (or a combination of the two working together), in truth, it’s the responsibility of everyone on the team to understand, ask about, and help gather project requirements.

Continue reading to learn more about:

1. Why the whole team matters

2. The different types of requirements

  • Business requirements
  • User requirements
  • System requirements

3. All the Rest!

Why The Whole Team Matters

Initially, it might seem easy to answer the question: “what does the client want us to make?” But as you start to pick apart that question, the layers become more and more complicated: “Ok, so they want a website with the goal of lead generation –

 

  • How will we market to those leads?
  • What sort of design would cater best to the client’s brand and goal(s)?
  • If we need forms on the website, what information do we need to gather about the users?
  • Where will the data be stored?
  • Are automated emails going to be a part of this?”

…And so on and so forth. See how it can get really complicated, really quickly? And often times, the client doesn’t even know the answers to half of these questions. Why? Because it’s not always their job to know the “how”: that’s what they’re paying YOU to do, as the digital agency!

At the start of project planning, your Project Manager or BA might have the perfect document structure in place to record all project requirements, but there are a multitude of requirements categories that will need to be addressed and understood before a project can begin, and this is where consulting with the whole team comes into play.

Business Requirements

Business requirements are usually the first, and easiest, type of requirement to gather for a project. This is because business requirements are guidelines clients are most often able to speak to/provide themselves right from the start. Business requirements include information regarding:

  • Client’s branding
  • Client’s business objectives / end goals
  • Client’s targeted user-base
  • Client’s desired capabilities (high-level)

 

Some real life examples of business requirements would be:

Scenario 1 : The client wants to create an online store to allow users to purchase their products, but they want that store to be separate from their corporate site. However, the online store must have the same “look and feel” as the corporate site, as they would like to make it clear to users that the two are related.

Business Requirement: Company X’s new site must allow for e-commerce functionality and should exist separately from Company X’s corporate site; however, the e-commerce site must be in line with the branding and design standards of the corporate sit

Scenario 2 : The client has strong user bases in both North and South America. They want to be able to target both user bases with the same content, without the hassle of creating two separate websites.

Business Requirement: Company Y’s new website must be able to support both English and Spanish, so that content can be displayed in either language at the user’s preference.

Business requirements are critical to understanding exactly what a client wants from your team. At this stage, the small details don’t matter so much yet: first, you need to define the big picture. Ask yourself: What does our client require in order to meet their business objectives and long-term goals, and who should we target in order to do so?

Once you have a pretty good idea of what exactly your client wants in terms of a final product, and who they are trying to reach out to, now it’s time to define what exactly the user needs to experience in order for those business objectives and long-term goals to be met.

Requirements Pyramid

User Requirements

Every project’s aim is to make the client that commissioned the project happy – but what about the people who will be interacting with and using that project’s end result on a day-to-day basis? In order to meet your client’s business objectives and long-term goals, the actual user-base needs to be taken into consideration ahead of time. While the business requirements should have defined WHO the user-base should be, user requirements define WHAT those users need in order to have the best possible interactive experience. Whatever the goal of the project (lead generation, sales, education, etc.), there will be a higher percentage of success if the necessary users are kept engaged, interested, and coming back for more.

User requirements are usually gathered in documentation that takes advantage of a more visual approach. Wireframes and design comps are often started at this stage, to help outline user experience requirements more thoroughly. User scenarios and test cases are also defined, to make sure every possible way in which the user could interact with the desired product is thought of ahead of time. Better to be over-prepared than under-prepared! Take advantage of your creative team members at this stage, as well as your quality analyst(s) (or whoever will be writing and implementing test cases down the line).

User requirements usually include information regarding:

  • Website design

    • Page layouts and templates

    • Responsive design (if mobile/tablet functionality was a desired business requirement)

  • Sitemap / Site architecture / Site navigation

  • User inputs and outputs (places of entry, places of exit)

  • All possible user scenarios

    • If building an application, questionnaire, multi-step form, etc., what are the possible “pathways” a user can take?

Some real life examples of user requirements would be:

Business Requirement 1 : The client’s desired website must allow for e-commerce functionality.

User Requirement:  Because the client’s product-base has a variety of categories, products should be organized and navigable by category (ex: Kitchen, Bathroom, Outdoor Patio, etc.), so as to create the most straightforward and understandable user experience.

Business Requirement 2: Company Y’s new website must be able to support both English and Spanish, so that content can be displayed in either language at the user’s preference.

User Requirement: Users should be able to toggle between English and Spanish versions of the site via a language change button or drop-down field located in the global header.

Once both the business requirements and the user requirements have been thoroughly defined, now it’s time to move on to the nitty-gritty details of “how.”

System Requirements

Finally, it’s time to decide how the actual project will be built. Here’s where things start to get detailed and intricate. Now that we know what the client’s goals are, and what users need to experience in order for those goals to be met, it needs to be determined how, technically, that experience can and should be built. Budget, timeline, and resources are taken into careful consideration at this stage, and this is usually when the development team is brought in to help discuss. Questions such as “can this be done?” and “if so, how can we do it?” are debated, and it’s very important to be realistic: we all want to create the coolest possible finished products, but sometimes it’s just not possible given certain parameters. Often times, it’s truly a balancing act between creativity and budget!

Technical and functional system requirements usually include information regarding:

  • Which content management system will be used, if any

    • If creating an e-commerce site, which product management/e-commerce management system will be used, if any

  • Site hosting

  • Database structure, data transfer, data storage, etc.

  • Browser and device compatibility

  • Code logic per desired site features

Some real life examples of technical requirements would be:

User requirement 1: Because the client’s product-base has a variety of categories, products should be organized and navigable by category (ex: Kitchen, Bathroom, Outdoor Patio, etc.), so as to create the most straightforward and understandable user experience.

Technical Requirement: Magento will be utilized as the e-commerce management system, as it allows for the desired level of customization but also e-commerce functionality.

User Requirement 2: It has been determined that company Y’s new website must be able to support both English and Spanish, so that content can be displayed in either language at the user’s preference.

Technical Requirement: Because the goal of Company Y’s site is informational, and will be architected with Sitecore, all page templates should be duplicated and set up for both English and Spanish versions so that content for each can be entered separately by the      client. Language change button will be coded into the global header so that it appears on the front end, and recognizes which language option to display at any given time.

All The Rest

Once the business requirements, user requirements, and technical requirements have been gathered and are understood by the whole team, you’re in pretty solid shape to produce a high quality product for your client! Sometimes, depending on the scope and needs for the project, additional requirements documents are needed, such as an ARD or Analytics Requirements Document – which are becoming more and more important within the digital marketing space these days as useful tools like Google Analytics become more and more popular and critical for success.

Be sure to like and/or comment below, and follow us on social media to see how we’re applying our top notch requirements gathering skills on a daily basis here at Delphic!

TAGS:
« Prev Article
Next Article »