Your Game System Requirements DocumentDate Version x

<PROJECT NAME> SYSTEM REQUIREMENTS DOCUMENT TITLE PAGE

Give your game name, the release date and the version number of the document.

List all your team members and what they did on this document - you can use something like the tables below. This is for when someone new comes onto the project they know who to go to for help. The roles we'll have in class for this document might be

Book Boss - in charge of production and submission of the milestone deliverable. She takes all other people's input and organizes it so that it meets the formatting requirements, and turns it in.

Requirements Phase Team Lead - responsible for organizing the requirements effort by scheduling meetings, setting agendas and recording minutes for the meetings, working out who does what in terms of actual writing, coordinating with the Book Boss to get missing material, responsible for team communications with TA and professor.

Contributors - author various parts of the document and deliver them to the book boss.

If you can think of better roles, go with them.

Team Member email Role<Member Name 1><Member Name 2>

<Role 1><Role 2>

Configuration Change Record (CCR)Every time you update your SRD, a new line and version number are added to the CCR. Requirements evolve over time, which is okay, but it is important that changes be documented and acknowledged as changes.You don't have to keep track of changes until you turn the document in; that is, until you turn it in, you can just keep changing things and adding as you go without tracking what has changed. When you turn the SRD in, it is Version 1.0 of the doc and every time you change it after that, you have to show the changes in the Configuration Change Record below. This is essential - when you talk about changes to the requirements, you'll always reference an SRD version.

1

Your Game System Requirements DocumentDate Version x

Date

Version Changes/Additions Resp. Person

As an example, I changed the position of the attribute paragraphs and added a Glossary section to this document. The resulting configuration change record is shown below.

Date

Project Name (version)

Changes/Additions Resp. Person

8/20 Dots & Boxes Moved attribute paragraphsAdd a glossary

dcs

You do not have to reprint this document every time you make a change. Just make the changes in ink, and initial and date them. When too many ink marks accumulate, you can fold in all the changes at once and issue a new version of the document.

2

Your Game System Requirements DocumentDate Version x

1 PRODUCT OVERVIEWThe Product Overview paragraphs are frequently business-oriented descriptions, not technical. They are included in technical documents to give new members of the technical team insight into why they are doing what they are doing, and to allow the technical team that originates the document to articulate their understanding of the business picture. This is important because cost, a business concern, affects almost all technical decisions.Product Overview sections usually contains several subparagraphs, each describing the product with respect to some different business concern - some of the common ones are included in this template as subparagraphs, numbered 1.x. Some of these will not apply to the task you are doing. Think about them and complete them based on your judgement. If a heading doesn't apply to your project, write “Not Applicable (N/A)” under the heading.You won’t be penalized for tagging a section as N/A – if something honestly doesn’t apply, then it will only cost time, effort and money to track something that doesn’t move the project forward. If your management thinks that something does apply, they can enlighten you during a review, you can add it and all will be well.

1.1 Description of the ProductThis is a high level description of what the product does. In this class, this might be a very high level description of play of the game. In the real world, you might say this is a telecommunications billing tracking program that can service up to 200,000 customers, etc.

1.2 Purpose of the ProductThis is what the product is supposed to do: provide a computer implementation of a game, take phone messages, protect the nation from nuclear attack. "Make a bundle of money" is not at good answer here (unless you are building a counterfeiting machine) because this paragraph addresses what a customer would use the product for, not the business logic of creating the product.

1.3 Problem Solved by the ProductThis answers the question (for new products) “Would someone actually pay money for this?” or (for upgrades) “Why are would anyone buy this one, as opposed to what’s already available?” If someone is paying you to build something, either the product doesn’t exist, or there’s some perceived shortcoming in the existing ones: too costly, too big, too small, too complicated, wrong color, lacking specific features, etc - think PDAs. This where you say what you’re going to fix.

3

Your Game System Requirements DocumentDate Version x

1.4 Objectives of the ProductObjectives usually have some sort of measureable aspect to them, such as “capture 0.0001% of the automated Othello market,” or “Be bundled with Blue Hat Linux,” etc. The reason this is important is that it describes what success could mean for your business, thus allowing management to allocate resources appropriately. This probably doesn’t apply to a school project, but it’s an important category in business. This is where one of a couple of things happens: you get this information explicitly from a representative of the marketing department, in which case, marketing is setting expectations or, because no one told you what your goals are, you take a guess. In the second case, you are looking for guidance or confirmation so you can scale your efforts reasonably.

1.5 Special ConsiderationsOther. This would be anything that someone either managing the program or coming onto the program needs to know that is out of the ordinary for your organization’s culture and that might affect the outcome of your project: your company is planning a roll out of a major, complementary product in 6 months; your company has been purchased by Mickeysoft, so you may all may to move to the Artic, and you anticipate loss of key personel, etc.In your case, special considerations might be that only one of your group members is a coder, or that all your schedules are very tight, so you can only have an entire group meeting once a week, etc.

1.6 Benefit to BusinessThis is how this product fits into the overall business strategy: does it stand alone, or does it complement or enhance existing projects? Hewlett Packard, for example, has an articulated strategy of being their own fiercest competition, so many of their new products replace or compete with their own very successful existing products. The idea is that every time you look for a printer, for example, the best price/performance will be HP. For this to work and be profitable, the timing has to be judged very closely, because you have to stagger the releases, at least a little. In that case, this might be where the technical team gives a short exposition on “Why now?”For this class, this paragraph is probably not applicable, unless you define your business as graduating, in which case its application is obvious.

1.7 Schedule and Finance ConsiderationsThis is really an important section. Here’s where you consider how well the resources allocated to the problem match the scope of the problem. It’s included so (1) If it's given you by management, you can get a feel for whether the amount of

resources available is right for the scope of the problem, or

4

Your Game System Requirements DocumentDate Version x

(2) If management doesn't give you this, you have to come up with your own estimates and to make sure that management understands what you'll need to be successful.

If the resources you're given don’t match up with the description offered by the rest of Section 1, you either have an organizational problem, or you haven’t understood something. For example, if your Product Objective is to create the best selling computer video game in the country, but you are given six weeks and a team of three people to accomplish this, there is a disconnect - you are going to fail. Alternately, if your task is to build a minimally featured editor in Java and you've been given eight months and a team of ten, you probably misunderstood the problem description. Or your management could truly be technically unsophisticated about software and not understand what makes a job time consuming. Either way, more negotiation has to take place.In the case of this project, your schedule is actually 9 weeks. We used one week to select groups and projects and the last week is devoted to acceptance testing.

1.8 Expectations and Limitations of this ProductNo explanation required – this is where you write down some specifics so no one will be surprised. An example of a limitation might be that it will not be designed to be networked – so, Mr. Marketing, don’t ask! Or it will only run on Window platforms, not Unix. Items like this limit the expectations of marketing.On the other hand, you have to make sure your team understands the scope of the expected work, too - so if anything is particularly hard, you have to make sure they understand that inclusion of that characteristic is required. Networking is a good example of this, too.

1.9 Summary DescriptionVery briefly, what you know about the project. An example: “This program will be written in Java. Its primary target platform will be a Sun, running Solaris x.x. It will act as rule interpreter for the game of craps, for up to 5 people. The user interface will be point and click on graphical objects representing both the die and the crap table. Minimal help will be provided, in the form of error messages for incorrect input.”

1.10 Acceptance criteriaThis is a description of how you are going to use the test documentation. For big programs, this might state

“System Acceptance is based on completion of the following: (1) customer approved system acceptance test, performed in house with either a customer or customer represenative for witness and sign off and (2) completion of 24 hours of continuous operation by customer-provided operators with no critical failures, as “critical failures” are described in the contract.”

5

Your Game System Requirements DocumentDate Version x

This is not where the critieria are legally established, but it gives your team an idea of what they have to expect. It usually says who, what, where, for how long and to what standard.In the case of this game, criteria might be

“Game acceptance will be based on (1) successful completion of the System Test Procedure delivered as Milestone 4 and (2) three plays of the game without encountering any errors, as described in the User Manual, version 2.1. The system test and the game play will be done in JBE Rm xxx on a Windows NT platform, version xxx. Dr. Kaplan or his representative must be either the sole player or one of the players involved in the play.”

Note that it says "successful" completion of the System Test Procedure. This is so vague that it's meaningless legally - but it should communicate to your team members that you are going to have a System Test Procedure that you have to pass and you are going to have to let unfriendly users play the game in order to get out of this class alive.

2 APPLICABLE DOCUMENTSThis section lists all the sources you used in creating this document and can include all the documents you're going to deliver on this project.

2.1 Reference DocumentationOn jobs in the real world, you might refer to various specifications, such as the Enterprise JavaBean Specification, v2.0 or the J2EE Specification, v 2.1 or the MumbletyPeg Reference Implementation, v 3.1 under the Reference Documentation Section. Notice that I included the version number of the specs -this is really important. Specs change, too, and when you are providing an interface, which is what designing to a spec is all about, you have to make sure that you understand exactly what's in that particular spec. In this class, you'll probably be referring to one or more web sites that you used to look at sample implementations or your game. Also, it's a good idea to look up the rules of the game, either in a book such as Hoyle's Rules of Card Games or on line somewhere. Whatever you use to settle on your game rules belongs in this section.

2.2 Project XXX DocumentationThis is all the documentation that you are promising to deliver. At this point, you just put "TBD", which stands for To Be Delivered after each heading. The purpose of this section is to, again, set expectations for your team and your customer as to what you are going to be delivering. Also, during the maintenance portion of the product life cycle, if you include this section in every document, users will immediately know what documents are available.

6

Your Game System Requirements DocumentDate Version x

2.2.1User Manual

2.2.2System Design Document

2.2.3System Test Procedure

3 CONTEXT DIAGRAMA picture which displays a system boundary together with those things which are inside the system, and those that are outside the system plus their relationships to the system. See the example document to see one of these.A context diagram is really important because it helps to establish the limits of your responsibility. For example, suppose that a customer wants 100% reliability but mandates that you use Windows 3.0 (??!!) as the operating system. In that case, it doesn't really matter what you do - the underlying layer doesn't provide that level of reliability, so you can't either. In a context diagram, you could make it clear that your application runs on top of Windows, so you can't be held responsible for it's failings. Also, it helps your team to understand what their job is. For example, you might be responsible for building part of an Air Traffic Control application that listened for electronic emissions from airplanes and identifed the specific aircraft/flight from the electronic fingerprint. If you were responsible for developing the database that held all the signal characteristics for all the aircraft, that would be a much larger job than just building the software that looks for matches between an intercepted signal and a signal in an existing, formatted database.

4 PRODUCT DETAILS

4.1 Users

4.1.1Who they areName: Brief Description: Status: Favored,

Disfavored, or Ignored

This is a description of your users. The option to classify them as favored, disfavored, or ignored allows you to bound your work, identify “negative requirements” and set expectations with your customer. Favored users are those who have the specific problem that you are solving; if you don’t please them, you haven’t done your job. Disfavored users are those that you explicitly want to discourage from using the product; for example if your product

7

Your Game System Requirements DocumentDate Version x

was an adventure game with steamy sections in it, children would be disfavored users and you would want to come up with a way of keeping them away. Ignored users are those who will use the product, but the design will not be altered in order to please them or exclude them. “Negative requirements” are those that you might not think of unless you consider who you want to discourage from using your product, thus allowing you to put in the correct design hooks to allow whatever lock outs you need to. For example, if Unix had been designed as a commercial application and someone had considered hackers as disfavored users, Unix security might be better. Or maybe not - it might add too much complexity to the program to discourage disfavored users, but at least you'll have examined the issue and been in a postion to make a rational decision.As another example, if you're working on an office voice mail/telephone system, operated by an office receptionist, you might say that the receptionist, the system administrator, customers making incoming calls and marketing/sales/engineering employees making internal and external calls were all favored users. You might make telemarketing companies making incoming calls disfavored users, and you might make manufacturing employees making external calls an ignored group.In this class, in most cases, the typical user of your game is . . . you. One thing to keep in mind is that usually this is not true - most users of software products do not have degrees in computer science, don't care what their operating system is as long as they can run Excel on it, and use the mouse to interact with the computer, not the keyboard. These are important things to keep in mind.

4.1.2 Inclusion strategyHow you are going to represent the users you've identified? You can represent them in (at least) the following ways:

1. Surrogate – You tap someone to act as the customer representative. In a lot of cases in the real world, this is QA or the systems engineer.

2. Limited – You call on a real user to come and check what you’ve done.

3. Complete – the users are a constant part of your design process, frequently co-located at your facility. You're in luck here - if you choose to have college age, computer literate, English speaking people as your favored users, the labs in JBE are crowded with potential testers for your product.

The user responses can be assessed by behavior or judgement. If they are included by behavior, you watch them operate your creation and see what they do. If they go astray, you change something so they don’t. Inclusion by judgement is when you ask them what they thought while playing the game. Both are useful and you’ll use them both: I anticipate your team watching me, or someone else, play the game. You’ll notice the foul ups we make, then ask us why we did it. I might lie about something because I don’t want to admit that I don’t know how to use a mouse, so my judgement would be suspect – but you could probably see from watching me what the problem was and decide to either fix it or ignore it. What you might not

8

Your Game System Requirements DocumentDate Version x

see from just watching me is how frustrated I was because I couldn’t read the numbers on your playing pieces.

5 CONSTRAINTSConstraints are measurable requirements that must be met in order for the program to solve the problem. The section consists of the list of constraints, each specified in an objective and measurable way. The list is generated from the list of Defining Attributes (we'll get to those later) as well as other sources. Constraints are such things as supports from 1 to 5 players, responds to a mouse click within 1 second, scores range from 0 to 200, takes 1 second or less from application initiation for the first graphic to be displayed, must occupy less than 10 Mbyte of RAM, etc.

6 USE CASESA list of stimulus-response relations, which can be classified as normal, abnormal but possible, and beyond reasonable use. Again, you do this because it sets customer expectations, bounds your tasks and the use cases form the basis of your System Test procedure. The way this works, in this class at least, is that the use cases will define the content of your User Manual and your System Test Procedure, if you do it correctly, will fall directly out of your User Manual - so it's important to make sure you've identified most of your use cases at requirements time; a little time spent here will pay off over and over again. By the way, when you're doing this, you're almost guaranteed to have missed something, or to have made a wrong decision about what controls to use or whatever - don't worry, this is an iterative process.You have to define what is normal use of your game – that’s easy usually. Abnormal use is where someone is using something in a way that’s legal but unintended, as when someone uses Excel as a primary word processor. Finally, there are the things beyond normal use - such as using Word to generate you PhD thesis (there is one such person here ON THE FACULTY!). You have to think of these so you can understand what you’re NOT going to do. Error messages usually result from abnormal use running into some limitation, or someone trying to do something beyond reasonable use.Each use case describes a major task the user of the system might have, and each use case might several scenarios that describe in detail how the user accomplishes that task. For example, in a word processor, a use case might be "Formatting a Document", with sub-cases for "Formatting a Paragraph", "Formatting a Font", "Formatting a Table", etc. The word processor would have another Use Case for "Entering Information", with sub-cases for "Entering Text", "Entering Graphics", "Importing Data", etc. You should be aware that different design "religions" call these different things: sometimes the major area is called a Use Case - in that case, when the use cases

9

Your Game System Requirements DocumentDate Version x

are broken down they are called scenarios. In other systems, the major area is called an "analysis level" use case and the sub-cases are "design level". In this class, unless you are doing something that requires a lot of set up, you will only have one major use case area - Play of the Game - which will have a bunch of different sub use cases describing your game in detail.There are lots of ways to document use cases: check any UML book, there are books on use cases, they are covered in most software engineering texts, etc. In this class, your design level use cases must have the following qualities, at a minimum:

1. Each of the user's major tasks must be covered by a use case.2. The preconditions for each use case must be listed.3. The postconditions for each use case must be listed.4. The steps the user has to do to perform the tasks must be listed in order.5. For each step, the user actions and expected response of your system has to

be described in a general way.6. Use case coverage must be complete enough so that, at minimum, an

uninformed person could read the use cases and understand how to initiate the game, how to score points in the game, how to win the game, how to get help, what actions result in error messages, how to restart a game and how to quit the game.

The simplest way to do this is to write a paragraph about the high level use case, then each of its sub-cases.

6.1 NormalThese are all the activities a player would do in normal play of the game.

6.2 Abnormal, but possibleThis where you would put the the things that you could anticipate happening, but aren't along the normal path of use. In the case of the game, it would be such things as illegal moves by players.

6.3 Beyond reasonable useThis is where you firmly set the boundaries on your system. There may be none of these for a game, but if you were designing a light-weight data base intended for the home computer user, you might put a use case in this section where someone uses your database to track all the trades for the New York Stock Exchange. The last line of your use case might be something like "The application will explode in billowing smoke and sheets of flame two minutes after opening."

10

Your Game System Requirements DocumentDate Version x

7 FUNCTIONS/ BEHAVIORSA list of the system’s externally visible functions (or behaviors) describing its responses to certain stimuli. "Externally visible", in this case, means visible at the system display level. These are WHAT the system does, not HOW it does what it does. The functional requirements with the Constraints define the system’s behavior. In applications where you are given software requirements, as opposed to system requirements, the functions may be directly "visible" only when using test software. For this class, the effect of your functions must be visible to the user - if an activity doesn't have a visible effect, then it's not a system function, it's an implementation. The idea here is to leave as much freedom as possible for the implementers. As an example, one of the first games for computers was a space-adventure game based on Star Trek, where the ship got attacked by aliens, the crew had to fight them off, and the level of difficulty got higher as the game went on. The game didn't support much in the way of graphics or joy stick interface and it took three hours to reload when, not if, it crashed. Games like this are still be written today. To get into the right mindset, consider how you would write the requirements for that game so that the 1979 implementers and the 2002 implementers could work from the same requirements.Keep in mind that these are functional requirements, not constraining requirements. What this means is that you state what it does, not how many or how much (that should be in Constraints). That is, this is where you might write down “deals a hand of cards to each player”, but you wouldn’t say it has to complete the deal in 20 ms. The idea here is to keep everything as general as possible, in order to support potential reuse and to not force premature design decisions.Since they are functional requirements, they should be organized by function. Most simple computer games can be divided into two functional areas: User Interface and Game Rules. There are zillions of other, no doubt better, ways to partition your game, but these will do for most applications. After you've partitioned into functions, then you describe the required behaviors to support the function. Some activities won't clearly fit in your functions. If that happens a lot, then you've done a poor job of partioning. If it happens for just a few, then you probably just don't know enough yet to make a good decision. Put them somewhere and flag them to look at during design time to see if there's a better place for them.Next, you have to weight each requirement. Requirements can be defining, distinguishing, or blue sky. Defining requirements are those that you must have to have a solution. For example, if your checkers game doesn't have the notion of crowning, you don't have a solution. If your poker game doesn't have the notion of betting, you don't have a solution. Essentially, all game rules are defining requirements, plus whatever else you (or your TA) decide is defining.Distinguishing requirements are those that will set your implementation apart if it can do them, but you aren't making any promises. They should be used to make design decisions. For example, you might want to save your game state, but you aren't sure you can pull it off. You're deciding between implementing in C++ and Java and it looks like the Java implementation allows you to easily save game state - you go with Java.

11

Your Game System Requirements DocumentDate Version x

Blue Sky requirements are things such that if the solution fell out of the sky and hit you in the head, you'd incorporate it, but you're not going to expend any resources implementing it otherwise. In the real world, these are frequently customer requirements that come after the contract has been signed and the work scoped - you don't want to be rude, but sometimes they ask for really unreasonable things. For example, I once worked on a sub-million dollar program where an add-on requirement was to develop an artifically intelligent ship identifier based on electronic signature, geographic location and other platforms known to be in the environment. It could have been done, but it was at least as hard as the original job. So we wrote it down and called it a blue sky requirement, and ultimately came up with a really cheap little database search application that allowed them to do some manual filtering.

8 ATTRIBUTESDesirable attributes of your system are what you use to decide whether requirements are defining, distinguishing or blue sky. Attributes are adjectives that describe your system - things like fun, reliable, inexpensive, safe, risky, error-prone, small, etc. Attibutes can be intuitive and relative, instead of measurable and objective; that is, you can have an attribute of "fun" - and it's fun if you and your user reps think it's fun. Or a system can cost $10,000 and be "inexpensive" if all the other apps that do the same sorts of things cost $20,000 - think about cars: an cheap car would be a really expensive bicycle.Usually when you're building something, there are one or more attributes that are emphasized at the cost of other attributes - and you have to decide the order of importance of your system's attributes. For example, if you are building a graphics program, the two attributes "low cost" and "fast" might conflict; that is, it will be more expensive to make your program fast, so you have to decide which is most important. Frequently, "fast" and "reliable" conflict - think of compiler optimization switches that you can turn on and off - the reason is that some optimizations cause your code to run quickly, but can cause inaccuracies.For the games in this class, the defining attribute is that your game implementation follows the rules of the game, that is, it's "rules - compliant". Other attributes are usually relatively straightforward: fun, fast to load, fast to play, intuitive interface, etc. What you need to have here is an ordered list of whatever attributes you come up with: defining, followed by distinguishing.

9 RESPONSIBILITIESWho’s going to do what. You don't have to be too detailed. You list the milestones that are due this quarter and identify who's going to take the lead for each milestone and also designate a back up. Clearly, you don't know what your schedules are going to be like, but if you have one group member who is an excellent designer, you can tentatively give her the job of leading the design phase. There's no penalty for having to change your plan later, but you need to at least have a vague plan so every milestone is someone's responsibility.

12

Your Game System Requirements DocumentDate Version x

10 UNRESOLVED ISSUESA list of issues, to be resolved or transformed into assumptions. These are such things as Are we going to build our own graphics, or find some on the web?

11 ASSUMPTIONSA list of statements about the system being built or circumstances surrounding the project. Assumptions1 are hunches, self-evident, made with supporting evidence, or imposed externally.

11.1 Hunches Intuitive evidence only – you’ve got to choose one way to go, so you do based strictly on what your tummy tells you.

11.2 Self-Evident Obvious to all. Hmmm. It’s hard to think of a good example. I know this might cause contention, but it might be self-evident that this should be built in Java, so you have the graphics facilities and can work on the Sun machines where you have to test.

11.3 Supporting Evidence Assumptions that you made based on observable evidence. You might assume that the product had to have a graphical interface, since we’ve mentioned them several times in class.

11.4 Impositions Somebody outside the project says it must be so. This would be something like “Assume that when it’s time to code, we’ll buy you 8 development workstations, all with complete and identical development environments.” For this project, it's that your game has to run on either Solaris or Windows NT because that's what is in the labs. To test this assumption you could ask if you could demo on a laptop that you bring in that uses something else. (We'd say no.)

1An assumption may also be classified as critical if going to influence the design more than others.

13

Your Game System Requirements DocumentDate Version x

12 DATA ELEMENTSThis is just a list of things you know you have to keep track of. It's a first cut at game state.

13 DESIGN DECISIONS

13.1 Preemptive Choices The project leader takes both the initiative and responsibility.

13.2 Design ChoicesA list of choices made and confirmed by signing authority.

14 RISKThis section identifies and justifies what you perceive as the parts of your project that are most likely to cause you to fail. Risk has two components: probability of the occurrence of the event and the cost of dealing with the problem if it occurs - so you have to consider risk in two dimensions, likelihood and exposure. Likelihood is usually assessed as low, medium or high. Exposure is usually figured in dollars or schedule impact (which comes to the same thing).

14.1 Technical RiskThese are technical issues that must be resolved. A risk might be that you are counting on the speed of your processor doubling over the two year life of your project; so the risk is that the speed up won't be sufficient to meet your performance goals. The probability is moderate that this will occur. The exposure, however, may be huge; you might have to speed up a sorting (!) algorithm by a factor of two, or buy a much more expensive processor for each unit of your product that you sell, causing you to miss your price point.

14.2 Financial RiskThis will be Not Applicable for this class. In the real world, these are things like the fact that, since your product will take a team of ten engineers ten months to get to market, your company will have a million dollars in labor alone sunk in the product. If you have total assets of $1.1 million, this is a risk.

14.3 Schedule RiskThe only risk you have will be that you have eight weeks to the whole thing. In the real world, the technical risk above might be manifested as a schedule risk - if you

14

Your Game System Requirements DocumentDate Version x

don't get the processor speed up, it will increase your schedule by at least two months, resulting in a minimum of cost of carrying the project team for an extra two months or a maximum of death to your product by missing your window.

14.4 Risk Mitigation PlanIn this class, you have to choose what you think is the critical part of your application and get it running by the seventh week of class. It doesn't have to be robust or complete, just demonstrate that you have solved the primary technical problem you're facing. This will be something like developing and demonstrating the computer opponent part of the game of Othello, or the board set up and logic for Scrabble.

15 DOCUMENT CONVENTIONSSee the example.

16 SAMPLE DISPLAYSThese are hand drawn first efforts at what your game windows are going to be like. They are intended to be used with your use cases to see if you can actually "play" the game. They will be refined into something really close to the real thing in the next step, the User Manual. We expect somewhere between 7 and 10 drawings, and they can be hand drawn and not very detailed.

17 GLOSSARY AND ACRONYM LISTDefine any words you use that have special meanings and all acronyms that you use.

15