arXiv:1811.03482v1 [cs.SE] 8 Nov 2018
A Holistic Loo k at R equiremen t s Engineering in the Gaming
Industry
Aftab Hussain
a
, Omar Asadi
b
, Debra J. Richardson
c
Department of Informatics,
Donald Bren School of Information and Computer Sciences,
University of California, I rvine
a
aftabh@uci.edu
b
c
Abstract
In this work we present an account of the status of requirements engineering in the gaming in-
dustry. Recent papers in t he area were surveyed. Characterizations of the gaming industry were
deliberated upon by portraying i ts relations with th e market industry. Some research directions in
the area of requirements engineering in the gaming industry w ere also mentio ned.
Keywords: requirements, modeling
1. Introduction
The main goal of this work was to meticulously explore the status of requirements engineering
in the gaming industry. There have been several market research studies illust rating the vast growth
of the gamin g indu stry. One such example is ment ioned in Alves et al. (2007), where global
revenues in the gaming industry was found to $3.1 bn in as early as 2006. The market has grown
significantly since then, making the industry hardly ignorable in terms of the economic value it
generates.
In th is work, we observe the gaming industry with an requirements engineering perspective.
In particular, we see how requirements engineering practices in the gaming industry differ from
those in the traditional software industry. In order to do that we take a st ep by step approach of
understanding the gaming industry. We first see how t he gaming industry shares all the charac-
teristics of any market driven industry (Sectio n 2), where we then see the status of requirements
engineering in the market driven software industry based on surveyed literature. In the next step
we surveyed the general software engineering challenges that exist in game development, and how
they can impact requirements engineering p rocesses (Section 3). We then go deeper into studying
the characteristi cs of game requirements and how some researchers have tried to use them to l ever-
age the requirements engineering process (Section 4 ). In Section 5, we enlist current development
trends in the gami ng indust ry based on a num ber of surveyed papers, with a requirements engi-
neering persp ective. We present so me future directions for research in th e area of requirements
engineering for games in Section 6, and conclude the paper in Section 7.
2. An Overview of Software Development in the Market Driven Industry
In this sectio n, we emphasize upon software development in the market driven industry, with
a focus on requirements engineering (RE from h ere onwards) primarily based on the findings of
the work of Dahlstedt et al. (2003) et al. We first briefly explain how the games developm ent
industry is a market-driven industry, and how t his industry differs from the traditional software
development indust ry with respect to its t arget customers (Subsection 2.1). Next, we see how the
development process, i n particular the RE phase, in the traditional industry compares with that in
the market driven industry.
2.1. The Gaming Industry: A Market Driven Industry
Among the most widely cited works on the characteristics of a market driven indust ry is by Day
(1998). The following descriptions are given for a market driven industry in that work.
• “Make the customer the final arbiter”
• “Understand our markets”
• “Commit to leadership in the markets we choose to serve”
• “Deliver excellence in execution across our enterprise.”
From the above we can see that the current state of the market will drive the design decision s
of the product. The seeds of design therefore typically start to grow from understanding the char-
acteristics of po pular trends wi thin the domain of the product, who are the main competitors in the
domain, what are the characteristics of the target market segment, etc. The findings will then set
the tone for the d evelopment of th e entire product.
The most defining property of a market-driven industry i s t hat it targets the mass market, where
even a small segment of the market can include a large number of diverse customers ( Alves et al.
(2007)). This is typically not the case for the traditional software engi neering industry, where
customers are generally known to the soft ware vendors and projects are customer-specific. The
projects are built ground-up in a way where the goal is to meet th e goals of the specific customer
rather than to abide or follow the domain trends. Also in those industries, newer projects are often
improvised versions of previous projects, where previous designs are strictly observed. The design
development process thus typically follows a top-down approach.
Based on the above mentioned reasons, it is justifiable to classify the gaming i ndustry as a
market-driven industry. It is geared towards serving a large spectrum of customers. Since iden-
tifying specific evolving needs of each customer is challenging, t h e corporations in the games
industry pay a lot of emphasis on studying market research data, game postmortem websites and
game review websites like Metacritic and PCgamer to understand the recent trends in the gaming
industry. For instance, a number of recent (as o f 2013) trends are mentioned by Graft (2013);
live-streaming and video sharing will become standard for games and gamin g platforms, virtual
reality capabilities of games, console providers like Sony, Microsoft, and Nintendo opening up
to independent developers to publish games on the platforms of the conso le providers, offering
games before completion because players now are willing t o experience a game before they are
published, etc. These trends origi nate from the market and are crucial to observe while designing
games in order to compete in the games sector. The market driven nature of games development
thus cannot be over emphasized.
In the next subsection, we see how development practices, in particular RE, are performed in
a market driven in d ustry.
2
2.2. RE in the Market Driven Software Industry
For understanding the characteristics of RE practices in the market driven industry, we shall
mainly draw upon the findings of Dahlstedt et al. (2003) (2.2.2). But first we shall briefly ex-
plain th e different stages of RE in a traditional software engineering setting as per the definitions
of Cheng and Atlee (2007) (2.2.1).
2.2.1. Generic Phases in RE (Cheng and Atlee (2007))
Elicitatio n . This phase primarily comprises of u n derstanding the goals of t he system and
delineating the requirements that need to be met in order to fulfill t hose goals. The requirements
may include devising new functionali ties, modifying old properties of a system, etc. Techniques
used for this phase typi cally include stakeholder analysis (to ensure information is elicited from
all the relevant stakeholders), brains torming techniques for coming up with new requirements, and
feedback techniques for increasing the accuracy of the requirements. These processes m ay take
the h elp of models for guidance. As el icitation i s an early phase of RE, the models used at this
stage may not necessarily be accurate or highly formalized.
Modelling. This phase begins when the requirements have been refined to an acceptable level
of accuracy. Modelling helps to codify the requirement s in a consistent, coherent, and structu red
fashion with the help of formal notations. Formal notations raise the level of abstraction and spec-
ify detailed requirements of the system, such as the kind of data that is stored by an application,
and the kinds of operations that are performed on the data. The models generated are thus less
likely to be misunderstood by workers, for instance developers, in the subsequent phases of the
development process. Modelling is a challenging phase as it entails , opti mally identifying the
different subgroups of stakeholders/concerns/functionalities of a system and looking for opportu-
nities for transforming or combin ing models, etc. Different modellin g techniques are in use in
industry. One such example is scenario-based modelling.
Requirements Analysis. This phase comprises of analyzing the correctness of the require-
ments, i.e., looking for possibly conflicting requirements, under-defined requirement s, miss ed as-
sumption s, etc. The phase might require goi n g back to eli citation for further refinement of the
requirements. Different techniques have emerged to i dentify an optimal requirements set.
Validation and Verification. Valid at ion is by and large an informal p rocess of checking whether
the requirements in the requirements document of a project indeed satisfies the objectives of the
stakeholders. Verification is a more rigorous activity as it involves proving whether specific re-
quirements specifications provides the desired objectives. That is why verification is only possible
when a formal model of requirements exists.
Requirements Management. This phase involves tracing requirements artifacts and connecting
them with various software artifacts further down the developm ent stream, identifying opportuni-
ties for requirements evolution, getting in analytics and visualizations for requirements i n order to
aid future project decisions.
2.2.2. Variation in R E in the Market Driven Software Industry (Dahlstedt et al. (20 03))
Dahlstedt et al. performed a literature survey on market driven RE. They found that require-
ments of low priority are shelved in order to facilitate the early release of products, which is a
critical aspect in market driven software companies. Also, the requirements are initially invented
by the development organization rather than elicited from the customers, since there is no well-
specified customer segment. It is only later t hat customer inputs are incorporated with the help
of feedback mechanisms. This lack of specificity in the description of cus tomers could also be a
reason behind not having sign ificant requirements documentation or modell ing. Verbal communi-
cation is the primary means for conveying requirements. Validation tends to take the back seat in
3
RE in the market-driven setting as well and this could also be attributed to the absence of a specific
customer. Some forms of validation are generally post-release (through market surveys, prototype
reviews, etc). Requirements management, however, has been identified as an important area of
market driven development because of the crucial b enefit it could offer. Having s eam less require-
ments tracing mechanisms would enhance tracking product evolution and even maintenance. The
use of a common repository for storing the requirements has been advocated for this purpose.
Two di stinguishi ng RE phases in the market driven setting is requirements prioritisation and re-
lease planning. As time-to-release is a survival attribute in market driven development , it becomes
important to sieve out the m ost im p ortant requirements and also check for any interdependencies
between requirements.
Dahlstedt et al. also performed a qualitative research study using semi-structured interviews
with seven Swedish software companies with a market-driven development focus in order to in-
vestigate to what degree their literature survey findings were practically observed at the time.
Although most of those findings matched with th ei r practical findings, there were a few differ-
ences. For instance, time-to-release was more of a crucial attribute for those companies wh o had
more competit ors in their domain. Also, all their surveyed companies did document requirements.
3. Challenges in Game Development
In this section, we s hall visit the challenges in game development and how some of them pose
a problem t o RE. Because project data are hard to o btain from g ame companies
1
, most previ-
ous works [Flynt and Salem. (2004), Petrillo et al. (2009), Bethke (2003)] have reviewed publicly
available game pos tmortems to elicit the characteristics and challenges in game development. We
first briefly explain postmortems in Subsection 3.1, and then discuss problems found in Subsec-
tion 3.2.
3.1. Postmortems
Game postm ortems are reviews of completed game projects written by developers who h ave
actually worked on them. In these review developers write about the experience they had while
building their games: the software development methodology they used, the i ssues they faced on
each phase of the software development, issues they encountered with project coordination, etc.
Postmortems are posted on popular game review sites li ke Gam asutra, where other registered users
of the site can weigh in their opinions on the postmortem s as well. Postmortems do not have any
fixed structure, and are written in a very informal, note-taking style. However, they create fruitful
discussion seeds on game development issues. Below is an extract from a postmortem of the game
Diablo 2 developed by Blizzard En tertainment
2
.
“The Diablo II team comprised three main groups: programming, character art (everything
that moves), and backgrou n d a rt (everything that doesn’t move), wit h roughly a dozen members
each. Design was a largely open process, with members of all teams contributing. Blizzard Irvine
helped out with network code and Battle.net support. The Blizzard film department (also in Irvin e)
contributed the cinematic sequences that b racket each of Diablo ’s acts, and collaborated on the
story line.”
Despite their informalism, postmortems reveal current practices that are bei ng adopted for
building games in the real world, which could assist in building perspectives on the development
side of games.
1
Game companies do not reveal data in order to maintain a competitive edge with their domain counterparts.
(Petrillo et al. (2009))
2
http://www.gamasutra .com/view/feature/131533/postmortem
blizzards diablo ii.ph p (accessed Ma rch 2015)
4
3.2. Problems
Based on their literature study, Petrillo et al. (2009) elucidate a number of problems that are
encountered in game development: (1) scope problems, for instance, feature creep - initial scope of
the project is inadequately defined and consequent development entails addition of new function-
alities which becomes an issue for requirements managem ent, (2) scheduling problems - underes-
timating the times various project tasks could take and consequently setting amb itious deadlines
for milestones that are hard to meet, (3) crunch times, i.e., times before finalization of a project
tend to get more work heavy in the gamin g industry than crunch times in t he software industry,
(4) technological problems that may arise due to working on new platforms that have not suffi-
ciently m atured with respect to deployment, etc. It ought to be noted that in addition to these
problems, common problem s in the traditional software industry are also found in the gaming
industry (Petrillo et al. (2009)).
Petrillo et al. (2009) also performed a survey of 20 postmortems of completed game projects
to elicit what software development problems were practically facing within the gaming in dustry.
The most common problems found are showed in Figure 1 which was obtained from their paper.
Problems of “over budget” and “crunch time”, although mentioned to be prevalent in literature,
were found to be less significant problems in the projects they studied by Petrillo et al.
Figure 1: Common Prob lems in Games Development. Petrillo et al. (2009)
Overall, most problems of the gaming industry are shared with those of the traditional soft ware
industry. However, there are a few differences. For instance, game development teams consist of
more diverse teams in term s o f job roles - there will be story writers, UX desi gners, developers,
music artists, etc. This could lead to p rob lematic issues for communication as each have different
perspectives - thi s could lead to splits within the team (Petrillo et al. (2009)). In addition , elabora-
tion of games requirements is tricky as most of them are related to the “fun factor” which is highly
subjective in nature (Petrillo et al. (2009)). In the next section, we shall take a look at some works
that have attempted to logically navigate such requirements in games.
5
4. Understanding Games Requirements
The previous sections have elaborated on the nature of the gaming indus try and thus formed a
foundation for understanding the impact on RE in th e gaming industry. In particular, we can now
understand th at( Alves et al. (2007)): (1) elicitation of requirements is difficult from the broad cus-
tomer set that typical gaming companies have, (2) the subjective nature of the requirements further
complicate requirements elicit at ion, (3) being a highly creative industry, the gaming indu stry will
always find it challenging to balance out “fun factor” requirements with critical non-functional
requirements(Callele et al. (2005)). In this section, we look at Callele’s works on understanding
game-specific requirements.
4.1. Callele’s Works on Game Requirements
Satisfying emotional requirements are highly important with regard to the success of a game.
The main challenge of working with emotional requirements with the design phase has been with
accurately specifying and representing them due to their highly subjective natu re. Callele et al.
in Callele et al. (2006) and a number of other works propose method s t hat t ake a considerable
step in deciphering emotional requirements. In [Callele et al. (20 06)], they dichotom ize emot ional
requirements into two aspects: intent and artistic context. The intent of an emotional requirement
is a verbalization of exactly what t he designer of the game wants the player to feel in a certain
moment of the game. The artistic context is the means which the developer would use to actually
induce those feelings in the gamer.
Callele et al. also proposed visualizations for emotional requirements. For instance, they pro-
posed emotional terrain maps, em otional i ntensity maps, and emotion timelines as visual mecha-
nisms.
Callele et al. (2008) presents a very interesting work in h ow emoti onal requirements coul d be
used in priorit izing security requirements for the game. The mai n motivation of the work was
that emotional discontentments in the game cou ld override security requirements, and thus it is
important to gauge the security risk with respect to the emot ional diss at isfaction it can cause in
among th e consumers. Other works of Callele in clude the proposal of cognitive requirements for
games ( Callele et al. (2010b)), and the embodiment of game-specific requirements into experience
requirements ( Callele et al. (2010a)).
5. Current Development Practices in the Gaming Industry
In this section, we look at a few works in order to portray the general, recent, themes in
software development within the gaming industry (Subsections 5.1 to 5.7). We take stock of th ese
works with an RE perspective in Subsection 5.8.
5.1. Model-Driven Game Development (Reyno and Cubel (2008))
In this work, the authors discuss a model-driven approach to modern video gam e develop-
ment. In the past, gam es could be developed by a single p ro g ram mer in a few weeks’ worth of
work. Now, video games need teams of dozens to hund reds of people and several years of work.
The teams include artists, marketers, voice actors, and musicians i n additio n to the programmers.
As such, the development teams needed to move away from ad-hoc d evelopment and waterfall
methodologies into something more suitable for the colossal task of creating such a complex soft-
ware system. The teams tried in corporating compo nent-based development and agile met hodolo-
gies with some success. The paper seeks to extend this success to model-driven d evelopment o f
computer games. The main goal of model-driven development here is to abstract away the finer
6
details of the game. Thi s is done wit h high-level models such as structure and behavior diagrams
as well as control diagrams. By expressing the g ame’s design in this way, it allows management to
gain at least a rudimentary understanding of the game design and help alleviate the commun ication
problems encountered in previous development methodologies.
5.2. Cheating: Gaining Advantage in Videogames (Consalvo (2007) based on review of Henr icks
(2009))
In th is review, the author reviews the book Cheating: Gaining Advantage in Videogames by
Mia Consalvo. He tackles the questions Consalvo proposed in the book, including who should
define cheating and how it should be poli ced. The first part of Consalvo’s book offers a hist orical
journey through the culture of video games from the early days in 1980 to the present . T he re-
viewer took note of t he battle between manufacturers who wish to exert control over th e players
and external forces who try to profit by undermining the manufacturers. In the middle of thi s b attle
are the players who seek to m ake a name for themselves as to p gamers.
The second part o f Consalvo’s book narrows its focus to how players i n teract in online multi-
player games and how cheating impacts this form of play. Consalvo id entified three types of play-
ers: purists, m oderates, and hardcore players. Purists believe that players sho uld not be seeking
external aid other than asking friends for advice. Moderates believe that walk-through s and guides
are acceptable forms of aid. Hardcore p layers believe that only other pl ayers can be cheated, not
the games themselves.
The remainder of Consalvo’s boo k focuses on the social interactions associated with cheating.
Parts of these interactions include the search for cheati n g programs to gain unfair advantages over
other players. Game developers should address these possibilities in the design of their games.
Perhaps the anti-cheating measures can be captured at the model level as specified in the previous
paper.
5.3. Comparative Analysis of Porting Strategies in J2ME Games (Alves et al. (20 05))
In this paper, t he authors discuss the problem of porting mobile games from one device to
another. The ever-increasing number of mobile devices combined with the ever-shortening release
cycle for these mobile devices is putting a new type of pressure on mobile game developers to
quickly port and release versions of their mobile games for all available mobile devices. Here, the
authors present and discuss several of the challenges facing mobile game developers with regard to
porting the m obile games from device to device. The challenges include different device hardware
features, diff erent execution availability and application size limits, different profiles, different im-
plementations of the same profile, propri et ary APIs, device-specific bugs, and internationalization.
The authors then discussed various case studies of mobile games t hey ported from one device
to another. In each case, a different porting strategy was used and analyzed. Each presented their
own drawbacks, such as poor code maintainability or highly granular code changes necessary.
The challeng es that these authors presented with porting mob ile games exist for desktop games as
well. In the world o f comp uter gaming, it’s very likely that each gamer’s computer has different
hardware than any other computer. The developers must acknowledge this during the design phase
so that the game can be developed in a way that can scale automatically up or down depending on
the hardware.
5.4. Proposal of Game Design Document from Software Engineering Requirements Perspective
(Mitre (2012))
In this paper, th e authors propose a Game Design Document as an improvement over the exist-
ing standard for System Requirements Specifications. The document consists of several important
7
sections, which will be outlined below. The authors goal with thi s document is to improve upon
the understanding provided by a System Requirements Specification.
The documents first section is the overview. Thi s section sum marizes the ob jectives of the
game and attempts to keep t he team on-task . The next section is game mechanics, which deals
with the game elements present. Next is the game dynamics, referring t o any interactions within
the game. Following that is the aesthetics section, dealing with anything the player perceives with
their senses. The next section, experience, addresses the expected player experience. Finally, the
assumption s and constraints list all the technical limitations present.
These sections of the Game Desig n Document improve u pon the System Requirements Spec-
ification by adding information that was not previously contained, such as the aesthetics of the
system. This improvement provides a more complete specification of t he game and allows for
better communication between different levels within the development team.
5.5. Extending Use Cases to Support Activity Design in Pervasive Mobile Games (Valente and Feij´o
(2014))
In this paper, the authors propose a lang u age to define activities in mobile games. The authors
point out that there has been very little research in this area and that there was a dire need of
a bridg e between the preproduction and productio n phases of development. There needed to be
a way to design activities in these very diverse and complex processes. The main focus here is
that tradit ionally, software has been focused on productivity, which is a measurable idea. Games,
however, focus on entertainment, which is completely subjective and cannot be reliably measured.
A secondary focus is that games are creative projects rather than strictly engineering projects,
which adds a preproduction phase to development not present in traditional software. The gap
between this new preproduction phase and traditional production can cause many games to fail
before they have been completed, which is why the authors sought to introduce this new language
to bridge the gap between the two phases.
This paper attempt s to tackle one o f the non-functional requirements of games: enjoyability
and entertainment value. Since these cannot be measured reliably, the only way to improve them
is to streamline the development process rather than the product itself.
This paper also attempts to tackle the root cause of nearly all defects in requirements: commu-
nication. By creating a new language with which developers can communicate, the autho rs seek
to solve t h e problem of mis understanding one another by ensuring a formal language about which
there is no ambiguity whatsoever.
5.6. Game Development: Harder Than You Think (Blow (2004))
In this work, the author discusses th e reasons why game development today is so much harder
than it was only 20 years ago. He divides th e difficulties into two categories, difficulty from size
and complexity and difficulty from highly domain-s pecific requirements, but notes that there is
significant overlap between the two when the domain-specific requirements force the project to
become more complex.
The author identi fies the too ls, environments, and workflows as p art of the reason for in credib ly
complex software projects in the gaming industry. According to the author, the current develop-
ment environment on Windows was not meant for the type of development necessary for video
games. Microsoft Visual Studio was built for Visual Basic and C# m ainly, not for C++, but the
only vi able C++ compiler and environment on Windows remains Visual C++. However, even
games are developed to run on multiple platforms, and this means that the tools and environments
need to be synchronized across them all. The author also i dentified t hat many companies do no t
8
consider the complexity of the code when they establish their workflows and do not allot any
time for necessary code refactoring, contributing to the complexity of the code and increasing the
amount of time it takes to develop quality code.
The aut hor identifies engine code, depth of simulation, and profiling as some of the highly
domain-specific requirements that contribute to the difficulty of writ ing video gam es. The author
further breaks down engine code into mathematical and algorithmic knowledge and the wis dom
to know how the algo rithms will i nteract when coupled together. The simulations in video games
are incredibly complex themselves and require much more domain-specific knowledge than is
normally required for software. Also, since the simulation is intended t o run in real time, the
developers would like to ensure that all resources are being used as efficiently as pos sible, leading
to the profiling of CPU and GPU usage to determine where inefficiencies lie.
5.7. Component Based Game Development A Solution to Escalating Costs and Expanding Dead-
lines? (Folmer (2007))
Keeping i n mind the ideas about complexity from the previous paper, this paper dis cus ses the
concept of using commercial off-the-shelf (COTS) components in video games rather than writing
all the components from scratch. The author argues that development teams can significantly
reduce development time in this way but then run the risk of struggling with component integration
and architecture complexity. The paper also touches on s ome domain-specific components and
their problems.
Many of the decisio ns that mu st be made regarding using COTS components in a vi deo game
boil down to what the COTS components offer the developers. There is no point in using a COTS
component if it does not perform a necessary function in the code.
5.8. Linking it all together with the RE perspective
Each of these papers p resent s some isolated aspect of requi rem ents engineering in video game
development. Reyno and Cubel proposed using model-driven development to enhance communi-
cation between developers and management. Along the same lines, Valente and Feij proposed a
new formal lang uage with which developers can clearly comm unicate with each other regarding
intended activities in the vi d eo game. Again addressing communication among the development
team, Cuauhtmoc and Snchez proposed a more detailed Game Design Document that offers more
information than a System Requirements Specification.
Consalvo identified that video game developers need to consider social i nteractions in th ei r
games while determining the requirements due to the prevalence of competition among players
and some players’ tendency to cheat the system to beat other players. Th ese so ci al actions are the
defining characteristi cs of many video games today and must be accounted for in the development
process. Both Blow and Folmer addressed the rapidly increasing complexity prob lems of modern
video game development and stressed that these issues must be tackled sooner rather than later.
Blow mentioned t he issues of workflow on a complex project while Folmer tackled the problem
of COTS component s increasing the complexity of the project.
6. Research Opportunities for RE in Games
In this section, we look into a number of opp ortunities for research in RE within the gaming in-
dustry based on the findings of Callele et al. (20 11)(Subsection 6.1), and suggest a relatively novel
research area of requirements engineering by relating to a recent work that we did (Subsection 6.2).
9
6.1. Research Opp ortunities (Callele et al. (2011))
Callele et al. cites that there is considerable research potential into the contextual interpretation
of requirements. They give examples of how a certain requirement may be viewed as a functional
requirement in the story design context but may be viewed as a non-functional requirement in the
implementati on phase. There is also work left to be done to view how the interpretation of re-
quirements as functional or non -funct ional can have an impact on the different phases of RE, like
elicitation, requirements validation, and requirements m anagem ent. Another interesting research
opportunity elicited by Callele et al., which is based on their work on prio ritizing security require-
ments with the help of emoti onal requirements, is h ow emotional requirements could be used to
formulate requirements to identify and handle destructive stakeholders (for example, players who
deliberately destroy other players in an action game) in the run of pl ay. Finally there are research
opportuniti es in understandi ng the reasons why certain game genres are p opular in different seg-
ments of the consu mer market - such research could b egin investigations by dividing the market
into segments based on age or geog raphic location. The findings from such explorations would
help in predicting needs and thus building more quality requirements for games.
6.2. Reverse Engineering Requirements in Games
There is significant scope in finding efficient and effective techniques in reverse engineering
requirements in games. The development of the requirements document (or the Games Desig n
Document) is not a standardized and t horough process in th e games industry. This is mainly due
to the diverse nature of the customers (As mentioned in Section 2) that makes requirement elicita-
tion challenging ( Natt och Dag (2002)). We thus believe reverse engineering requirements from
games can be a viable option to generate requirements, particularly for reuse of games design
and components in the future. However, there has not been much work in this aspect. Reverse
engineering descriptions of large legacy systems is challenging, particularly in eliciting in all non
conflicting descriptions of all components of the game. T here have been recommendations of
reverse engineering requirements in an incremental way, i.e. decomposing the system into subsys -
tems and generating requirements models for each of those subsystems Bluepri nt (2010).
In [Asadi and Hussain (2015)], we reverse engineered the requirements of a popular multi-
player, online s imulation game, Euro Truck Simulator 2 built by SCS Software
3
. We tried to
observe the decompose-and-construct p hilosophy suggested in Blueprint (2010). To this end, we
found two techniques t o be useful: the i∗ approach (Yu (1997)) to generate the system goal mo dels
and the rich picture method (Monk and Howard (199 8)) to generate the system vision model. Our
work, however, adopted an entirely m anu al approach. We believe th ere is considerable scope for
research in seamlessly integrating reverse engineering techniques that are prevalent in architectural
retrieval in the RE frame. In particular, there is s cop e for identifying requirements patterns, and
exploring opportunities for automatically codifying requirements, perhaps with the help of formal
notations.
7. Conclusion
In this work, we have explored the status of requirements engineering in the gaming industry.
We have studied how the gami ng indust ry shares many of the traits of a market driven in dustry. In
addition, we saw what probl ems are unique in th e gaming industry, particularly wit h regard to their
comparison with the tradit ional software industry. L iterature pertaining to software development
3
The g ame has sold over 500,000 units as of April 2014, http://e n.wikipedia.org/wiki/Euro Truck Simulator 2
10
in the gaming industry and an assessment of how they impact RE process was made. We also
reviewed some recent works on gaugin g requirements that are unique t o the creative indu stry.
We bel ieve streamlining RE processes in the g aming industry can help in resolvin g many of the
bottlenecks that exist in the gaming industry. For reusi n g RE techniques in the traditional software
industry may not be sufficient, particularly because of th e fact that requirements in the gaming
industry are distinctive in nature. Novel approaches, such those proposed in [ Callele et al. (2008)]
need to explored.
References
Alves, C. F., Ramalho, G., Damasceno, A. L . G ., 2007. Challenge s in requ irements engin eering for mobile games
development: The meantime case study. In: RE. IEEE , pp. 275–280.
Alves, V., Cardim, I., Vital, H ., Sampaio, P. H. M., Damasceno, A. L. G., Borba, P., Ramalho, G., 200 5. Comparative
analysis of porting strategies in j2 me games. In: ICSM. IEEE Computer Society, pp. 123–132.
Asadi, O., Hussain, A., 2015. Euro tr uck simulator 2: Reverse engineered requirements document. Tech. rep., Depart-
ment of Informatics, Bren School of ICS, University of Califor nia, Irvine.
Bethke, E., 2003. Game Development and Produ ction. Wordware Pub lishing.
Blow, J., Feb. 2004. Game develop ment: Harder than you think. Queue 1 (10), 28–37.
URL http://doi.acm.org/10.1145/971564.971590
Blueprint, 2010. Reverse engineerin g requirements.
URL http://www.blueprintsys.com/back_to_the_future_reverse_engineering_requirements/
Callele, D., Neufeld, E., Schneid e r, K., 2 005. Requirements engineering and the creative process in the video game
industry. In: Proceedings of the 13th IEEE Interna tional Conference on Requirements Engineering. RE ’05. IE EE
Computer Soc ie ty, Washington, DC, USA, pp. 240–252.
URL http://dx.doi.org/10.1109/RE.2005.58
Callele, D., Neufeld, E., Schneider, K., 2006. Emotional requirements in video games. In: Proce edings of the 14th
IEEE International Requirements Engineering Confere nce. RE ’06. IEEE Computer Society, Wash ington, DC,
USA, pp. 292 –295.
URL http://dx.doi.org/10.1109/RE.2006.19
Callele, D., Neufeld, E., Schneider, K., 2008. Balancing security requirements and emotional requirements in video
games. In: Proceedings of the 2008 16th IEEE Internatio nal Requirements Engineering Conference. pp. 319–320.
Callele, D., Neuf eld, E., Schneider, K., 2010a. An introduction to experience requirements. In: Proceedings of the
2010 18th IEEE Intern a tional Requirements Engineering Conference. pp. 395 –396.
Callele, D., Neufeld, E., Schneider, K., 2010b . A proposal for cognitive gameplay requirements. In: Requirements
Engineering Visualization (REV) , 2010 Fifth Internationa l Workshop on. pp. 43–52.
Callele, D., Neufeld, E., Schneider, K., 2011. A report on select research opportunities in requirements enginee ring
for videogame development. In : Fourth International Workshop on Multimedia and Enjoyable Requirements En-
gineering (ME RE 2011) - Beyond Mere Descriptions and with More Fun and Gam es , Trento, Italy, August 30,
2011. pp. 26– 33.
URL http://dx.doi.org/10.1109/MERE.2011.6043942
Cheng, B. H . C., Atlee , J. M., 2007 . Research directions in requirements e ngineerin g. In: 2007 Future of Software
Engineering. FOSE ’07. IEEE Computer Society, Washington, DC, USA, pp. 285– 303.
URL http://dx.doi.org/10.1109/FOSE.2007.17
Consalvo, M., 2007. Cheating: Gaining Advantage in Videogames. The M IT Press, Cambrid ge, MA.
Dahlstedt, A. G., Karlsson, L., Persson1, A., och Dag, J. N., Regnell, B., 2003. Market-driven requirements engineer-
ing proc esses for software pro ducts - a report on current practices. Submitted to D evelopment of Product Software
14.
Day, G. S., 1998. What does it mean to be market-driven? Business Strategy Review 9 (1), 1–14.
URL http://dx.doi.org/10.1111/1467-8616.00051
Flynt, J. P., Salem., O., 2004. Software Engineer ing for Game Developers. Software Engineering Serie s. Course
Technology.
Folmer, E. , 2007. Compone nt based game development: A solution to escalating co sts and expanding deadlines? In :
Proceedings of the 10th Inter national Conference on Component-ba sed Software Engineering. CBSE’07. Springer-
Verlag, Berlin, Heidelbe rg, pp. 66–73.
URL http://dl.acm.org/citation.cfm?id=1770657.1770663
11
Graft, K., December 2013. The 5 trends tha t defined the game industry in 2013.
URL http://www.gamasutra.com/view/news/207021/The_5_trends_that_defined\_the_game_industry_in_2013.php
Henricks, T. S., 2009. Research direction s in requirements engineering. In: American Journal of Play. pp. 532–534.
URL http://www.journalofplay.org/sites/www.journalofplay.org/files/pdf-articles/1-4-book-review-6.pdf
Mitre, H. A., 2012. Proposal of game design document from software engineering requirements perspective. In:
Proceedings of the 2012 17th International Conference on Computer Games: AI, Animation, Mobile, Interactive
Multimedia, Educational & Serious Games (CGAMES). CGAMES ’12 . IEEE Computer Society, Washington, DC,
USA, pp. 81– 85.
URL http://dx.doi.org/10.1109/CGames.2012.6314556
Monk, A., H oward, S., 199 8. Methods & tools: The rich picture: a tool for rea soning a bout work context.
interactions 5 (2), 21–30.
Natt och Dag, J., 2002. Elicitation and mana gement of user requirements in market-driven software development.
Licentiate Thesis.
Petrillo, F., Pimenta, M., Trindade, F., Dietrich, C., Feb. 200 9. What went wrong; a survey of problems in game
development. Comput. Entertain. 7 (1), 13:1–13:22.
URL http://doi.acm.org/10.1145/1486508.1486521
Reyno, E. M., Cub el, J.
´
A. C., 2008. Model driven game development: 2d platform game prototyping. In:
GAMEON’2008, (Covers Game Method ology, Ga me Graphics, AI Behaviour, Game AI Analysis, A I Program-
ming, Neural Networks and Agent Based Simu lation, Team Building, Education and Social Networks), November
17-19, 2008, UPV, Va le ncia, Spain. pp. 5– 7.
Valente, L., Feij´o, B., 2014. Exte nding use cases to support activity design in pervasive mobile games. I n: 2014
Brazilian Symposium on Computer Ga mes and Digital Entertainment, SBGAMES 2014, Porto Alegre, Brazil,
November 12-14, 201 4. pp. 193–201.
URL http://dx.doi.org/10.1109/SBGAMES.2014.11
Yu, E . S. K., 1997. Towards m odeling and reasoning suppo rt for early-phase requirements engineering. In: Proceed-
ings of the 3rd IEEE International Sympo siu m on Requirements Engine e ring. RE ’97. IEEE Computer Society,
Washington, DC, USA, pp. 226–.
12
