As I said in the last post, we aren't going to go through every step. We're skipping a step that is very important in industry. It's the why step. Why are we building this. Normally you need a good answer to this like money, productivity, or public perception. Our reason doesn't need to be that good. Our reasons are for experience and fun. Throw in some others if you want.
Requirements
Now that that's out of the way lets get to the development. We're going to start with requirements. Basically what does our program need to do.Requirements:
- Menu (it makes the game look more legit)
- High score list (a little competition is good for you)
- Game modes (practice, challenge, etc)
- Difficulty (so that it doesn't get boring)
- Hints (so that you don't give up on hard mode. The first hint may be a category like on Wheel of Fortune more hints may just reveal letters)
- GUI (this isn't text based)
- Timer (combine this with the difficulty and we'll be able to get some good high score ranks)
- Music (just to keep it lively)
- Automatic word picker (who has friends these days?)
Add more requirements if you'd like. Just know that you'll need to do the extra leg work as we go along. These requirements will typically come form someone know as the Project Sponsor. This could be the client who hires your company, the receptionist who is tired of copying and pasting all day, or maybe the person in house who came up with this amazing game idea. What's important is that there is one person designated as Project Sponsor so that you can go back and ask them if you're on the right track.
Previously I said we would be doing this using the waterfall method. One problem with this method is it doesn't allow room to make changes. If the Project Sponsor forgot to tell you some requirements that's just too bad. Put it on a separate list and add them in version 2.0. If you stop what you're doing and go back to incorporate new features it's called Scope Creep. Just like the creepers in Minecraft scope creep is bad news. Stay away from them or they'll blow things up. Scope creep will slow things down and make you lose sight of what you were trying to do. We started with a game of hangman and we may end up with a platformer where you must jump on the letters in the right order as they flow up the screen (let's file that idea away for later). Don't let scope creep happen.
Story time
Some places call them Scenarios some call them Use Cases we'll go with use cases because it's fancy. What they are is a story from the USERS perspective of what's happening. We aren't going to look at any implementation specifics right now. Use cases will have several fields to fill in. What they are and what they contain will depend largely on where you work. We'll include some of the more common ones that you'll see.Name - This is... the name. Name the use case using verb noun pairs. Remember those commercials "verb it's what you do"? That's what we're going for we want to do things like Start Game or Show Hint. Get it? Lets keep going.
ID - These are easier to reference from other documents. Give each use case a unique ID. This may be job specific. Some places may want something like H-001 (for hangman 001) or maybe A (for use case A). Doesn't matter what you do here just be consistent.
Use Case Type - There are four types in two categories Detailed/Overview and Essential/Real. I don't completely understand the uses for all of them but here's a shot. Detailed vs Overview - Overview is a high level look at the process. For our hangman game an example would be saying "the user guesses letters until they get the word right or they lose." Detailed would be "user enters a character from keyboard or selects character from list. Game updates word blanks if the letter is in the word. Game updates stick figure if letter was not in the word." Essential vs Real - Essential is bare bones. It's what is needed to get by. For us this would be much like the overview "user guesses letter until they win or lose." Real covers as if actual data was being used. "User selects 'e' the game fills in the e's or progresses the stick figure. User selects 'e' again, game give user an error message and tells them to guess again."
Actors - These are people or other outside systems that interact with our system. Our only actor this round is the user.
Description - This should be short. A single sentence should be enough to describe what the use case is going to cover. If it can't be short you need to simplify the use case.
Importance - This is a way to prioritize when we get to implementation. In our game the music is a low priority but the game wouldn't work so well without a word picker. Like the ID's this is whatever method you want to use or whatever standard your company makes you use. Some ideas are 1-10, High - Medium - Low, Color Gradients or hex values if you want to be nerdy (priority level 0xFF (that's super high priority)).
Stakeholders - We don't have these so don't worry about it too much. Stakeholders are the people invested in the project. This includes the project sponsor, managers, users/customers, etc.
Triggers - These can be time based or event based. It describes what causes the use case to happen. For us this would be like viewing the high score list. The trigger would be the user clicking on the high score button.
You will also want to include any relationships this use case has with other use cases. Remember the description section I said you should simplify it if you cant give a short description? The split may be listed here as an association of some kind. I'll only mention a few right now. Association can be said to "work with" something ex. "Jim works with Frank". Extension can be said to "add on to" something. My glasses extend my eyes. Glasses extend eyes. Include can be said to "contain" something. A car contains an engine. Lastly, generalization is just a more general type of something. Car is a generalization of Mazda.
Now, let's get to the actual story (sorry this is a long post but we'll make it through and we only need to cover it once). The flow of events is the story part of our use case. It describes the flow of events that the actors go through. There's a normal flow which is an ordered list of events that the user will typically go through (guess letters one at a time until the end is reached). There's an alternative flow which may happen if something goes wrong (user guesses a letter they already tried). And there's a sub flow where you can give more detail about what happens.
Well that pretty much covers what a use case description is. There is also a use case diagram but we aren't going to do one of those because of how simple this first project is. The next post will contain my use cases so hang tight and try it out for yourself in the mean time.
No comments:
Post a Comment