Hello, I was going to do this part about task analysis but I realized there’s a couple things I missed about the requirements in the last part I need to cover. I’ll save task analysis for the next part.
The notes I have on requirements are as follows:
- There are several types of requirements, which can be put into functional & non-functional categories. Functional describes what the software does, while non-functional describes what the software has.
- Good requirements have the following qualities:
- Necessary – an essential part of the product
- Verifiable – is not vague & can be measured
- Attainable – it can be done
- Clear – simple, concise & expresses a single thought
- Complete – not dependent on other requirements
- Consistent – doesn’t contradict or duplicate other requirements
- Some common problems that come up while forming requirements:
- Language – each requirement can usually be written in a format like “the system/user shall provide [requirement]”. There are formal conventions for some words like “will” for statements of fact & “should” for goals. There are many other titbits on this, but I’ll leave it there.
- “How” not “What” – avoid describing the implementation
- Poor assumptions – simply caused by lack of information
- Operations – avoid describing the use, e.g. open a dialogue box, press the up key, etc
- Wish lists – avoid lists of “nice to have” features
- Over-stringent – too much detail
- You should prioritize requirements so that core requirements are not neglected in favour of minor ones.
- It’s normal to encounter new requirements as the project progresses.
So with these considerations, how does it change my requirements?
First off, almost all of my requirements are non-functional. Saving is probably the only functional requirement, & that one’s already implemented. I guess its because (good) games, unlike other software, are more about their intrinsic value. We typically play games for what they have rather than what they explicitly do (other than entertain & engage us). Games can of course do more, but for this project I’m aiming for simplicity, so I won’t change what the game ‘does’.
Are they necessary? For the experience I have in mind, yes they are. Verifiable & complete? All except “tactical combat”, arguably. Combat will have to rely on other features & user testing to be ‘tactical’. Attainable, clear, & consistent? I would think so. The only mistake is language, but that’s more of a format issue.
With these considerations, there’s little change to the requirements themselves:
Prioritization in brackets, ranging from 0 (very low) to 10 (very high)
- (0) The system shall provide a save feature (already implemented as part of RPG Maker)
- (6) The player shall take part in tactical combat
The system shall provide…
- (10) 4 player characters & classes
- (9) Warrior abilities focusing on dealing damage & protection
- (9) Mage abilities focusing on powerful spells & enchantments
- (9) Thief abilities focusing on deprivation & agility
- (9) Healer abilities focusing on restoration & buffing
- (9) Several different enemies
- (7) 1+ boss(es)
- (8) 1+ Areas where enemies can be encountered
- (5) 1+ Safe areas
- (5) Items & equipment
It’s a bit hard to prioritize them as they’re all relatively important & need to be interrelated to each other to work best. Hence I’ve tried prioritizing them based on how large of a role they play. At least prioritizing them has given me a good order to follow when designing & building the game.
- The player characters are the most important simply because they’re what the player will be playing the game with. Very few things are more important in games than how the player will interact with it.
- Enemies have high priority since the player will be encountering them many times as they play, so they need to remain engaging throughout the playthrough. PC abilities are of the same prioritization as I feel they will need to be designed in tandem to best bring out the qualities of the player characters. Bosses have a lower priority since they are rarer than standard enemies, but I still aim to make them good.
- Safe areas are not as important as enemy areas since the majority of gameplay will occur where the enemies are. The safe areas are more for resting & giving direction on where to proceed to next.
- It seems weird to put tactical combat at a low priority, but since it relies on much of the above to be present, I feel that having some form of combat is of higher concern than how tactical it is.
- Items have a relatively low priority as, in my eyes, they’re more there to augment the experience; though that doesn’t mean players should find them useless.
- Saving is set to zero since, while highly important, it’s already implemented in the manner I want it to work so I don’t need to concern myself with it.
I had the feeling “developing concept” would take more than four parts to get through (at least one part for each step I brought up last time). Task analysis by itself is quite extensive so I may divide it into two parts as well.
Given the job hunting issues I’ve brought up recently, these stages will take a good while for me to get through. I imagine I won’t move onto prototyping until mid-July onwards. Then again, in my experience with time estimates, things always take twice as long as you think they do. We’ll see.