This series of blogs is my attempt at thinking through some of the issues surrounding using Atmosphir as a tool for teaching the ICT systems life cycle. The first blog post contained the different stages and the following blogs are looking at each stage. At this point I am not trying to come up with a definitive guide, merely think through some ideas for its usage in the classroom. At the end of this I may very well have a scheme of work in place.
In my previous post I briefly looked at analysis and feasibility studies. At the end of that section a pupil should have a redefined problem definition or idea about what they wish to build. This should include some basic investigation into what the end user wants. This is crucial to have prior to moving onto the requirements stage as it will form the basis for developing a good requirements document.
How do you approach this stage with a class?
The intention I would think would be to create a reasonably detailed requirements document which would form the basis of the design stage. As I am still teaching myself the design process within Atmosphir I may miss out a few sections however the following would probably be good categories for stating requirements for the new game
- Plot / Background
- Gametype and rules
- Scenery, setting and World rules
- Character usage
- Enemies, objects and interactives
Writing up the requirements for each category
Instead of being quite strict about how pupils should write up a requirement for a category I think it would be better to accept or encourage pupils to create requirements in any form they wish. This could be mindmaps, drawings, lists of ideas. For older pupils though a structure for the requirement could be useful.
I'm aware that adding drawings could be construed as beginning the design process already. I think this points to some of the issues with the systems life cycle in any case in that it is stagnant and too structured. Under the principles of Rapid Application Development most games ideas would probably morph from idea to design and be created fairly quickly but I do think that it is important for pupils to understand some of the thought processes involved in moving from idea to reality so that they do have some structure when they approach it themselves.
It would essentially lead to a better design process in any case. One thing which pupils could fall victim to in the design process if they don't structure their ideas properly is 'feature creep' and concentrating on putting out achievable requirements is part of that process.
