I'm a software engineering student with a game development focus. How big of a part does requirement analysis play in game development?

I'm asking because I'm trying to decide whether to take a class on requirements analysis. Here is a description:

An in-depth study of current research and practice in requirements elicitation, requirements, analysis, requirements specification,requirements verification and validation, and requirements management.

Would this type of knowledge be useful for an independent game developer? (The alternatives are artificial intelligence or software architecture.)

  • \$\begingroup\$ To clarify, what are your alternatives? \$\endgroup\$ – ChrisE Mar 21 '11 at 17:05
  • \$\begingroup\$ Yes, shed a bit more light on your situation, please. Is this something to take in addition to your core coursework or are you trying to determine if RA is part of your core? \$\endgroup\$ – Jason Pineo Mar 21 '11 at 20:08
  • \$\begingroup\$ What's involved in your software architecture class? If it's geared more towards designing a system then I'd definitely suggest taking that. Requirements analysis consists of "I don't care how I do it, what do I want my software to do?" Designing a system consists of "I know what I want to do, how can I achieve it in the most efficient way?" \$\endgroup\$ – Ray Dey Mar 22 '11 at 1:30
  • \$\begingroup\$ Any applied tool/technique that will help you avoid Analysis Paralysis will be useful. \$\endgroup\$ – Patrick Hughes Oct 20 '14 at 16:20

Requirements analysis will be incredibly useful, whether you're an independent developer or you work for a big company. Requirements analysis lets you break down your project into manageable chunks. It lets you estimate the time your project will take, and weigh the value of a feature against your desired development schedule and required effort.

If you're in a larger indie game company, it will help you work together with other developers and content producers to make sure everyone's always got something to do and you can meet your development targets. If you're working for a big corporation, learning requirements analysis will make you one of the few developers at the meeting who can actually give a realistic time estimate for a feature instead of just pulling a number out of your ass.

In addition to all that, requirements validation could include things like unit testing and verification of features, which is invaluable for a developer without a large QA department at his back.

  • \$\begingroup\$ +1 Everything said here is correct, as well as somewhat addressing the idea that you might end up doing corporate programming until you've made it in the indie scene. \$\endgroup\$ – ChrisE Mar 21 '11 at 17:01
  • \$\begingroup\$ How could it not be useful? You have to analyze anything you do in a structured manner. Just because some terms are vague doesn't mean it is impossible to quantify. \$\endgroup\$ – johnny Nov 19 '16 at 0:49

I think this class will have between zero and very little relevance to game development. Certainly the semi-formal or formal methods you mention do not get used in my experience.

Games typically have incredibly fluid requirements, and even if it were possible to invest time and best practices into gathering requirements, much of what you'd end up with are meaningless and vague terms referring to fun, addiction, immersion, and so on. Very rarely will you have very clearly defined deliverables because, as much as we like to pretend making software is engineering, it's actually more of a craft, given the variety of different ways that programmers can express themselves. This goes double for games.

  • \$\begingroup\$ I hope "fluid requirements" isn't a euphemism for "feature creep". :\ I disagree that "much" of what you'd end up with is meaningless and vague terms such as "fun", "addiction", etc. Those represent non-technical requirements, which are a subset of a truly thought out requirements document. \$\endgroup\$ – PatrickB Mar 21 '11 at 19:05
  • 2
    \$\begingroup\$ I think fluid requirements certainly is a euphemism for feature creep, but if you want to compete in a retail and hit-driven environment, you need to accept feature creep from day one. The sort of things that you can learn by gathering and analysing requirements for a traditional 'software customer' are too different from how entertainment software needs to work. In particular you have one major problem in that your client is not your end user, and another major problem in that technical requirements can't be pinned down when you know that feature creep is inevitable. \$\endgroup\$ – Kylotan Mar 21 '11 at 19:19
  • \$\begingroup\$ I don't believe he said he's competing or even making a product that sells. A lot of indie games aren't designed to compete with retail games, they usually aren't even on the same playing field as AAA titles. Hell, Steam shoves all of the indie games into their own little sandbox, probably as more of a warning label. When your an indie developer, you, by definition have control over what you want to do. If you didn't then you'd be partnered / invested in, and you wouldn't really be indie then, would you? Either way, I don't seem to find feature creep in whatever hobby games I work on. YMMV. \$\endgroup\$ – PatrickB Mar 21 '11 at 23:15
  • 1
    \$\begingroup\$ I don't think independent normally means 'hobby games', it normally means 'small company not reliant on publisher funding'. As such your client/customer situation can be simpler than I suggested above, but you can be arguably even more susceptible to market forces. But at the end of the day most formal requirements analysis is going to come up short because it is incredibly hard to qualify what a "business need" is in terms of a game. Games differ significantly from other software in this regard and thus I would humbly suggest that other ways of specifying the software are more relevant. \$\endgroup\$ – Kylotan Mar 22 '11 at 2:59
  • \$\begingroup\$ What are the other ways? \$\endgroup\$ – johnny Nov 19 '16 at 0:45

Requirements analysis is much more aimed at corporate software, with formal communication channels and that kind of thing, little to none of which will exist for an indie developer. It's not very useful for games because many requirements cannot be formally tested or verified. If you have a toolbar and you say, "Clicking this button should drop down a menu with XYZ on it", then you can pay someone virtually nothing to click the button and see what happens. Is your game fun? That's a whole different kettle of fish.

RA can be useful for determining if the game functions; but when it comes to things like balance, replayability and other factors that determine the ultimate fun factor of the game, then it's difficult or impossible to test them. So ultimately, it depends on whether or not you're going for an excellent implementation of an existing idea; or whether or not you're looking for success in novel gameplay.


Skip it.

What area of Game Development are you interested in going into? I'm assuming Programmer but...

Designer: They write a lot. A whole lot. There is usually a design document which communicates the designers vision but for everyone else except the producer or publisher you'll normally get the information from the designer themselves.

Programmer: The lead determines the technical requirements which will depend hugely on the platform and the asset pipeline. You'll learn how to do this as you work with your lead on the job.

Artist: Again its the lead artist along with the lead programmer who usually set the requirements for art assets. Learn on the job.

Requirements analysis, like the course they will most likely be teaching, is useful for big corporations trying to justify spending money and for outsourcing. And its often done by someone who once coded and has possibly since forgotten. stab

If you plan to go indie take a business/accounting/management subject. You'll need it to survive and not get screwed. Good Luck.

  • \$\begingroup\$ I also would assume programmer, since he tagged it programmer ;) \$\endgroup\$ – The Communist Duck Mar 20 '11 at 11:21
  • 1
    \$\begingroup\$ -1 So, you not only missed that the person tagged it for programmers, you also missed that it was for indie development, which would immediately imply that there wouldn't be a tech lead to learn from. Requirements analysis is useful--even when not doing full system specs--learning how to get in the correct mindset to analyze problems. Additionally, the practice in writing will always be useful if the need arises to make a pitch to a publisher. Your advice, frankly, neither addresses the target audience nor provides any useful insight on the topic. \$\endgroup\$ – ChrisE Mar 21 '11 at 17:00
  • \$\begingroup\$ -1 Agreed. Enough crappy software out there that doesn't do what people need and enough indie games that suffer from terrible designs that don't solve the technical problems and devolve into endless rewrites and unreleased games. Formal methods are a formality which indie games may not explicitly go through, but having the background does lead to a "stop and think" mindset rather than "code and fix" which is all too prevalent. Coders are a dime a dozen, and yet quality software so rare. You do the math. \$\endgroup\$ – PatrickB Mar 21 '11 at 18:59
  • 1
    \$\begingroup\$ Ha ha ha. All game development, especially indie, is about being agile and iterating on a core idea. Requirements analysis has nothing to offer and is for the most part a front heavy process. So I generalized my answer. If they plan on going indie having a network of semi-experienced developers and artists will be hard to do without. So either you need to be a genius in all areas of game development and business or you find mentors, a la tech leads etc. Try not to be so sensitive guys. \$\endgroup\$ – bkersten Mar 21 '11 at 22:54
  • 1
    \$\begingroup\$ @PatrickB Requirements analysis wouldn't affect how a piece of software is designed. Requirements analysis is full of useless pieces of information that a games developer would hardly ever use (use case diagrams especially spring to mind). It's a topic that is pretty much geared towards stakeholders and hence corporate environments. I agree that the developer should list requirements (features) but that should be common sense. Designing a piece of software is a completely separate topic which requirements analysis barely touches on (at university anyway) \$\endgroup\$ – Ray Dey Mar 22 '11 at 1:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.