Product Req Spec

The prodcut requirements specification is a very important document in the design of a new product.

It describes what the product must be and do, without going into ANY technical details like 'how'

The reason that this is an important document is twofold. Early on, it is used to design the more detailed functional specifications (which describe the 'how' of the product) and later on it can be used to check that you are vaguely on target, and still making the product that you initially intended to.

This document can also be used as a 'design goals' thing - the team can all read it to make sure they know what they are aiming for, something that can all to easily be lost while you're in the depths of arcane code.

For a mod team, it is also important as the first design document - and is used to show the world what it is you intend to do, and to recruit team members who are interested in helping.

Some sources

Just for once, I'm not talking out of my bum on this one - I actually have some links for you.

• Wavelength - their howto
• More wavelength - oops, somebun already did this diary idea ;)
• The TC bible
• Ceej's black book - Beware ambition!
• Leper arena - an example
• GamaSutra - a 'what to' guide

How

Now, I'm not going to bother talking about formal document structure, or even document management methodology (storage of documents, naming ddocuments so that you can find them, revision control - old versions of documents) because as the old proverb goes 'there are a million ways to parise the sky - and all of them are right'

Read a management systems textbook if you don't know any method, but just pick a method you re comfortable with and stick with it. A little bit of effort spent on organising your documents is worth a lot of pain finding them later. But a lot of effort here will just cause a LOT of pain later, as you struggle within an overly complex and confining system.

No, what I am going to discuss here are a pair of different methods of writing this document with a team.

1. Commons debate

Argue. Argue a lot. Sit in a room with coffee and doughnuts and argue. At the end of it, whack out your bible on what the game is.

Refinements. Take LONG breaks away from that table to try things out, play with them a bit, consult with other people about what is possible. Also, just letting your subconcious mull things over while you go play some other game can really help avoid pointless opinion bashing.

Have some single person who has the final say on anything. Try to reach consensus, but when it's impossible, someone needs to make the call.

The advantages of this system are that you have a single document, probably with priorities built into it, from the start. It can be your bible.

The disadvantages are that it's inflexible. Just because something fits the document doesn't make it the right thing to do.

So, on the plus side, you know what you are making, and you will end up with SOMETHING. The disadvantage is you might not end up with what you really wanted. And in a year or two's time, who will remember WHY you made the decisions that you did?

2. Melding

Everyone writes something. Either about the whole project, or a little bit that they find interesting.

Then you come together, combine them, find the areas where they don't match, and try to spot the holes that you have left

Seperate, do it again. Repeat until you have a workable document.

The advantage is that areas of responsibility fall into place naturally.

The disadvantage is that some bits might never get done, or not be given the attention they deserve. You also get ego syndrome as people protect 'their' bit of the document from change.

3. Spiral

You saw it coming a mile off - a mix between the two systems. The important thing to do is to keep coming back and revising the document as the work proceeds. This stops it getting stagnant, though at some risk of annoying people by obsoleting work they have done.

A mix of debate and 'go away and work on your own then come back with the answer' tends to produce FAR better results than just one or the other though.

I choose this method :)

And here it is - The product specification, version 0.01.01

The Alpha Conspiracy Product Specification Verion 0.01.01 - May 09 2001 0. This document Is the product specification document for 'the alpha conspiracy' - preliminary version. It is intended to set down the basic intent of the product, and be continually revised as the project works along. 1. Goals To create a game which can be seen as a sequel to 'syndicate wars' To create a game that an average gamer can play in half hour bursts To create a game with an innovative scoring and 'secret moves' system based upon 'nifty combos' To make a story that an avid gamer will play through for twenty hours or more To develop the tools which will be used to create the game The game must be fast paced and fun, and have some form of multiplayer component to encourage community support 2. World and Story The basic story outline and world background can be found in the earlier design documents (first impressions and lasting impressions) but to quickly sum up: Secret agent type person with athletic and silly futuristic/supernatural special powers (teleportation) does standard special agent type stuff (blow up target, rescue hostage, beat up bad guy, steal secret plans) for a grey organisation in the dark future world of megacorporations that syndicates protrayed. The game focusses upon a three fold playstyle - firstly action gaming as you collect rewards for 'stylish' maneuvers - secondly observation and puzzle solving as you attempt to collect secrets (some trading element here too) - and thirdly a branching story of hidden politics as you attempt to uncover and work for the real force behind your organisation (presumeably the shady 'alpha conspiracy' of the title) 3. Desired Impact The game must make a profitable return on any investments made. Not a huge profit, but if a team puts in 'x' hours of time making it, I expect to get at least 'x' hours of satisfaction knowing that people are playing it, and enjoying it. A modest goal, but modest goals are attainable. I don't expect to set the world on fire with the next CS, but I'd like to have at least a small group of people who play it. 4. Timescale A three year release date has been handed down as a requirement. I will amend that and say that we should have an initial beta in two years, and then revise it at six monthly intervals. Internal beta's should be more rapid. 5. Where to go next A review of the current technologies should be made to assess what currently exists that we can build on. The actual tasks are yet to be decided, and should be split up in consultation with the team members. Recruiting team members starts now, and is on-going.

Right - get your butt back to catnews or take a gander at the previous episodes of this fantastic adventure into the mind of someone pretending that they can write instructions on how to write a game without writing a game:

1. Story telling
2. Game design
3. Initial Concept
4. First Impresisons
5. Lasting impressions
6. Development models