Make Better Games – You Need To Know About Requirements

Running an Indie Studio and being able to make better games requires consistently creating a successful product and writing great software – or you won’t stay in business long. You need to not only hit your targets, but also make sure that you are hitting a target that the market finds valuable at the time you are ready to launch.

One of the best ways to make better games does not involve writing a single line of code – all you need is a requirements document.

Accurate, effective, and concise business requirements are the foundation that you need to start with to springboard your development cycle. Freelance developers, consultants, and even indies can benefit from strong requirements that guide development and make sure that you hit the target that you are aiming for.

You wouldn’t try to build a house without a blueprint, and you shouldn’t try to build a new product or improve existing IP without a strong requirements document. This document explains the needs of the customer and the team for the game or product, and lays out the plan to get there. Risks and dependencies will be identified from the business perspective, and this document guides decisions by identifying project milestones. You can start trying to hack away and figure it out as you go, but you will eventually end up paying the piper. This will costing you and your customers valuable time and resources as you have to redo development and fix misunderstandings that happened throughout the process. It is much better to build a solid base, and adopt a development process that starts by pouring the foundation with a requirements document.

While documentation is often the last thing on everyones mind when there is ‘real work’ to be done, it is necessary to avoid missteps and save precious development hours so we are going to run through the best practices to get you up to speed on industry standard processes for both game development and product development in general.

One of the most effective ways to start gathering business requirements is to define whose needs to we need to consider? In other words, who are the stakeholders that would be using the product that we are going to build.

Make Better Games by Identifying Key Stakeholders

The individuals that will be identified will vary greatly depending on the game, but by running through this checklist and adapting it to suit the studios needs we can define a process that allows for rapidly shrinking the list of people down.

Indie Studio Stakeholder Identification Checklist

1. cohorts that are affected by the problem (customers)
2. cohorts that will be impacted by the solution (customers)
3. who will end up implementing the solution (our team)
4. allies that can help the project to succeed (consultants)
5. subject matter experts who can provide knowledge (network)

If you are an established studio, you might already have a checklist in place – even if you didn’t realize it. Think about how you manage your community, your brand, and your relationships with consultants. Consider how you will get into contact, maintain contact, and manage the stakeholders throughout the project. All of this ties into your checklist, and will become second nature over time.

For most projects, in all types of different work environments, effectively engaging all key stakeholders is absolutely critical. Meeting stakeholders needs means actively engaging in conversations with them. Community engagement and team engagement need to align with overall brand management brand management. Bridging the gap between what you think your stakeholders want, and what they really want is an art in itself. User engagement is a quantifiable metric for analytics to use towards this end. Big data should used to help drive decisions but it can’t solve all problems. Conversations directly with stakeholders are the best way to drive engagement. Stakeholders may not be able to adequately define their needs however, as people often haven’t put a lot of time into thinking about their own pain points. They may not even be thinking about what they really like about products that they are using. We need processes in place to help get stakeholders on the same page, and working towards a common goal.

Depending on your team size, a stakeholder can be external or internal. If you are a solo developer, most of the time your stakeholders will be external to you. Examples include artists who are consulting for you, or audio engineers working on sound effects for your games.

Not being able to organize collaborative meetings in a consistent fashion is a showstopper for developing requirements. You need to have a normal cadence of meeting with team members, and stakeholders. A best practice in software is to utilize Scrum and daily stand ups to check in with team members. You can use these points identify blockers and address issues.

You won’t be meeting with all stakeholders at such frequent intervals though, so establishing needs is a high priority task. Focusing on making processes that cut to the core of what the stakeholder needs, and succinctly gets the job done.

Level Up Your Requirements Gathering With Effective Communication

Scope creep is a problem in every development cycle. It’s too tempting to add one more level, add another super crazy ability, or add just a few new enemies. Part of our job is to balance what is realistic for your budget, timeline, and team. It is key to spend time with stakeholders early in the process to ensure that you are able to determine the full breadth of project needs, and that you are able to communicate these to the rest of the team.

Requirement definition activities generate a lot of unnecessary needs and features. Balancing scope with effort means taking a hard look at what is strictly necessary for your product to compete. You have to cut down unnecessary elements from the main development cycle. In agile development we need to move cards to a backlog list in order to keep only essentials in the pipeline at this time. This trimming process needs to tie what is strictly necessary for the product to function. Failure to cut the fat can lead to unrestricted and unnecessary project effort and wasted development cycles.

Juggling the needs with the amount of effort required for a solution takes experience and knowledge at both the team and organizational level. This can help mitigate these risks until the team becomes more experienced, and the process becomes natural.

One best practices for guiding stakeholders into identifying requirements and managing project effort is utilizing a Project Scope Definition. This should encompass the entirety of the project and describes the level of impact that project will have within the organization. An effective scope definition states the final product, service, or result that must be delivered in simple, non-technical language.

Checklist to Upgrade Your Project Scope Definition

1. identify processes within the organization that will be affected by the project and how
2. pinpoint interfaces that the project has and the constraints surrounding them
3. what are the limits that the project cannot exceed, with respect to time, human resources, capital resources
4. find specific, measurable elements that will be used as a yardstick to measure project success

The project scope definition checklist is a key part of cutting scope. We need to evaluate every requirements against the standards defined on the checklist, and cut if it fails. Making better games requires cutting as many unnecessary requirements as is possible. This ensures sure that only the true requirements remain. This process, much like the Agile process itself, needs to be iterative and feed back on itself. This means that as we cut requirements, it is valuable to go back and evaluate the rest of the list.

Our goal is identifying requirements that can modified, combined, or are no longer relevant. We want to spend more time in this part of this process, as it is generally cheaper to make changes earlier on in a projects life. Spending more time on proper planning saves cost on what is generally a more costly part of the project; the time spent actually in development, testing, and gathering feedback from end users. Ultimately, time spent working through requirements pays massive dividends compounding throughout entire software development process. You will make better games, and stay on budget, by spending your time effectively. This is not the place in the process where you can save effort by skipping or rushing. Many teams have learned this lesson the hard way.

Make Better Games By Understanding Requirements

Many of us involved in small businesses end up wearing multiple hats throughout our day; from project manager, marketing lead, business consultant, to software developer – and sometimes or most of time we end up putting on multiple hats at once. Depending on the hat that we are wearing and the lens that we are looking through, the terminology or syntax that we use can be different. We start by breaking down what we consider a requirement as determining ‘who needs what when’.

To further establish some common ground, let’s define what we will consider a software requirement to be from the common Wikipedia definition.

“the description of what the system should do, the service or services that it provides and the constraints on its operation”

https://en.wikipedia.org/wiki/Software_requirements

We can sum this definition up with the word “how”. A software requirement is most effective when it describes how the software will function for the end user, and delivers a concise value proposition. We can compare this to a business requirement from the project management institute –

“Business requirements define what the organization wants or needs to be able to do once the project is completed”

PMI Learning Library

Our interpretation of this will be that a business requirement is going to be simplified to the “what”. These requirements are intended to represent exactly what the business wants or needs to accomplish. Business Requirements are nearly always high level requirements that affect the entire system, or an entire line of business depending on the organizational scope being visualized.

List Of Requirement Categories

Categorizing requirements makes it easier to recognize and assign priorities to them. When you have a large list of requirements, the first step to make sense of them should be to assign them to one of the broader categories below.

To dig deeper, the following sections dive into specifics for each requirement type and define roughly the boundaries between the different buckets.

Make Better Games With The Correct Stakeholder Requirements

Stakeholder requirements are requirements that represent the needs of a particular stakeholder or group. This group may be defined within an organization as a single department, such as an art department, who may need information specific to a particular user interface, art style, or brand guidelines. 

The requirements in this instance are tailored to the individual needs of the stakeholders, the art department, and would include only information that is relevant to their particular need, rather than taking a holistic view of how this report may or may not be used within the organization as a whole. While it is an extremely high priority for members of the art department to determine color palettes, consistent messaging, and brand highlights, this may be a lower priority to other departments or within the organization as a whole.

Make Better Games From Better Business Requirements

Business Requirements are nearly always high level requirements that affect the entire system, or an entire line of business depending on the organizational scope being visualized.  These generally come from the Executive level, or from those who are taking an organizational video of the business. This includes thought leaders who are tasked with “steering the ship” and ensuring that the business has plans for its future growth and survival. Generally executives are making plans that guide the organization through 2 year and 5 year intervals, which have to be reviewed quarterly in order to ensure that the plans fit with the current market conditions as well as the changing internal environment of the company. 

For many small businesses and indie studios, the business requirements are the lifeblood of the company. Long tail revenue through established IPs, branding and merchandising existing content, and identifying opportunities for developing new IPs can be thought of as launching points for identifying business requirements. Navigating the market and maintaining one’s position in it is the prime directive of the executives, and within the context of software development being laser focused in mindfulness that the product you are working are is in line with this directive will ensure that your product is not only great, but actually useful to the business.

Characterizing Functional Requirements

“Functional requirements are capabilities that the product must do to satisfy specific user needs.“

These include the very specific features the product must have. If you are developing internal tools, automation to help ease a process, or even building out a new video game, the functional requirements should be considered the core competencies of the product. Every single thing that the product can and cannot do should be written down and considered.

Examples of Functional Requirements to Help You Make Better Games

You should have a separate document that consists of all of your functional requirements. Every rule and system that will exist in your game should be specified in the document, and also assigned a priority. The features that have higher priority needs to be the closest parts of your core game loop, and you should decrease priority by determining if the feature is a “nice to have”. As you begin to specify your functional requirements, you can begin describing things in the format of “the system shall do X” or “the system shall be able to do Y”.

For a scoreboard system in a first person shooter, a sample functional requirement can be something as simple as “The system will display the kill count of every player in the game.”. This gives a clear task that can be assigned a priority, and also will translate well into a development sprint. We can also use a functional requirement for quality assurance purposes, and having it in this format makes testing the system extremely straightforward for anyone. It is easy to take a look at the requirement and figure out whether or not you are able to see the kill count for every player in the game. Documentation like this makes onboarding new team members easy, and validating their effort painless.

Representing Non Functional Requirements

“Functioning to the stated reason of this system they have little to do with the system. Qualities of the solution, or conditions under which the solution must remain effective.“

Non functional requirements are best thought of as items that are part of the entire package, but are not the stated reason the system exists. From a game developers perspective, in order to make better games we need to make sure that the game must be fun. The story must be a strong story and the game must not crash. These are not items that we can have as a sprint task, but they are still non functional requirements for the product as a whole.

Examples of Non Functional Requirements to Help You Make Better Games

Diving deeper into some of these items we can think about a minimum required frame rate within the game, that has to be met during all gameplay sequences. For UI interactions such as an inventory system, a requirement could be that the maximum number of clicks for any function in the system should not exceed 4 clicks. Platform specific items such as whether or not the product has a minimum or maximum screen resolution that needs to be supported, different operating system requirements such as Linux, Mac or Windows, and things such as requirements for internet connectivity and whether the application requires the user to have internet available at all times. The requirements for the system itself can be considered non functional requirements, such as a specific amount of available ram or a graphics card requirement.

It is important to keep non functional requirements well defined and visible. They are going to be items that may not be on the top of the minds of your team members but will have an outsized impact on the organization.While you are developing software in small pieces, you may not be focused on does this make the game fun – instead you can be enjoying a particular technical challenge. Having a written non functional requirement that the game is fun helps you keep focus on your scope around other requirements. Would it be particularly interesting to investigate an advanced pathfinding algorithm that is .1% faster or more efficient? Probably, but to the players of the game that is such a small factor that it has almost no impact on them. Your time would be better spent developing a stronger core gameplay loop, or working on tying together story elements in the overall game design. At an even higher level, an advanced pathfinding algorithm that requires a sufficiently advanced processor can actually hurt your game by limiting your audience. Non functional requirements help keep you on task, and maintaining clarity on what is really necessary.

Consulting Requirements – From The Outside Looking In

As a rule of thumb as a consultant, you generally start with whoever hired you within the organization as the launch site for your information gathering. Ideally this point of contact is the one which you will use to grow your own tree of knowledge and reach out to contacts within the organization to identify touch points and how information is flowing through the entire business.

It is important to note that while you may contact executives in order to ensure that the information you have gained is accurate, you want to make sure that you are not spending too much of the executive’s time. The goal is to obtain a relationship where you are always welcome to circle back to the executive. This is key because you will need to interface with top management often to ensure that that the information your are gathering is actually lining up with the information of the organization that the executive has. Any mismatch here is crucial to identify, as it means that either you or the executive has a misunderstanding of a business process. Either case can sink a new line of business and product, so identifying disconnects and resolving them quickly and efficiently is key.

It is a much better practice to have initial meetings and scheduled touch-points which you can use to follow up with when you have gained new or significant information. You do not want to report back on information too frequently, with too little new information, as this will likely be viewed as not the best use of the executives time and is a quick way to get on the list of people who will not be creating meetings anymore. 

Make Better Games By Getting The Right Requirements

The individuals identified as stakeholders form the basis for requirements gathering. It is important to keep in mind project scope, budget, and timeline throughout the requirements gathering process. Every end user will have their own needs in mind. Each stakeholder will not be considering the viability of what they are asking, only how it helps them. It is critical that you are mindful in separating all of their wants from needs. This is the best way to make better games and keep your games completed on time and on budget. Now that you have identified the key players, focus on the conversations that you can have. Every conversation serves as a stepping stone towards making better games.

Techniques For Kickstarting Requirements Gathering

Not all of these processes make sense to use all the time, or in every situation. It doesn’t usually make sense for you to have focus groups for internal tools, especially on a small team. A tool developed to streamline the asset import process lets you make better games faster. For something like this, you can focus on use cases and line of business KPI’s. Most projects will require you to work through the end user role-play. Imagine what type of person is going to be using this product.

Helpful Leading Questions For Requirements Conversations

For most product conversations, it is important to put yourself into the shoes of the user. If it is a game, imagine your audience. What time of day will your audience be playing this game? Is your game a 5 minute experience? Is the game a month long experience? Identify the ideal length of a typical session. We will apply the same questioning process to internal tools as well. If you are working on automating your game deployment process, think about how you have been handling your deployments currently. What time do your deployments occur? The deployment process involves what members of team? What are the most common things that go wrong in the process, and is there even a formal process? How do you respond to issues that come up in the process? Are systems in place for notifying the correct people?

All of these leading questions are important parts of building internal deployment tools. End user role-play, user interviews, and team brainstorming are the answers to most of these question. For solo developers and solopreneurs, this is a great opportunity to tap your network. If you don’t have a team to help with this part of the process, your network can step in. Chances are that somebody you know has encountered a similar problem, and already has ideas for a solution. They may also have other requirements that you have may have missed. Most importantly, they will able to view your requirements from a different perspective. Collaboration isn’t just useful in brainstorming, it can be useful at every step of the requirements gathering process. Ultimately, making better games is easier when you are able to stand on the shoulders of giants. So reach out! With the stakeholders identified you now can focus on leading conversations that generate the information you need to build requirements.

Wrapping Up and Making Better Games Together

Making better games requires generating ideas, making a plan, and putting the plan in action. This post contains a ton of information that has been gathered from years of experience and updated with insight from my multiple conversations with industry members. The information contained within has helped me personally with many of my projects, and I hope that you find it useful as well. It’s important to stress that you don’t need to apply the entirety of this process to every project at all once. Getting the team familiar with pieces of the document, and applying the sections that work for you and your companies situation is a great way to tackle the process. Building better software is incremental, and building processes that bring us closer to that goal are just as incremental.

I’m sure that there is a lot of great practices and concepts out there that I’m missing, so I’d love to hear how your studio is running things. Drop a comment with some ideas, and I’ll do my best to update this post with all of the information that is being shared. The best way to stay on top of the industry best practices is through knowledge and expertise sharing.