I’m a scientist (it says so on my BS and the fact that I’m going for a phd in computer SCIENCE!), so let’s get some scientific method all up in here. I’ve done a tiny bit of background research since last week, so let’s figure out what will probably be going into this paper of mine.
A Requirements Analysis is a software/systems engineering concept that gives a name to “figuring out what our next product needs to have” in formal terms. The key difficulty of a requirements analysis is that it must compromise between many conflicting conditions and influences and settle upon some middle-ground between differing perspectives. The resulting requirements analysis must be:
- Related to identified needs
- Defined to a level of sufficient detail for implementaion
That’s what wikipedia says an engineering requirements analysis must have. Some of those items, I’m not so sure what they’d mean for an interactive authoring system (since there is a lot of hand-waving and guestimates when it comes to objectively testing and measuring success in interactive characters) . Let’s see what else wikipedia has to offer us…
I will be involved in three major activities:
- Eliciting requirements/Requirements gathering: speak to designers and stakeholders, synthesize a list of requirements to analyze.
- Analyzing requirements: the requirements in the last step must be clear, complete, consistent, unambiguous, and resolve any conflicts.
- Recording requirements: summary list, documents, use cases, user stories, or process specifications
My “stakeholders” in step 1 include anyone with a valid interest in my system. Such parties will likely include: my advisers, fellow authors of interactive characters, fellow authors of authoring tools (especially for interactive characters), and anyone interested in interactive characters in general. These people are also my intended audience! I will need to interview as many of these people with first-hand experience as possible to get detailed, highly-focused knowledge. Discussions with less experienced stakeholders will offer higher-level ideas and ideals to consider. I must take clues gathered in this manner and repeatedly ask “why?” until ideas are distilled into measurable goals.
If I am using any theoretical systems as an example to actually implement these ideas (the ABL authoring tool!), then creating a concrete list of the actionable requirements of that system will also be necessary. A mockup (as I have done in the past for Character Creator, which was very helpful) will help sell and solidify these ideas into the final product. Use cases (examples that use this mockup as a play-through of how it will be used) will sell the final product.
PHEW! I think that covers the overview of what I will need; the hypothesis of what will be going into my paper to make it a successful requirements analysis of authoring tools for interactive characters. More background research is needed to discover what systems have come before in order to understand who specifically to interview, what questions to ask, and to lay the foundation of related works for the paper. A posting of that research will be trickling in next.