design_walkthrough
A walkthrough is a set of procedures and error-detection techniques
for group role playing. This exercise of role playing allows an
independent group to walk through the requirements as a team.
How do we do that?
<![CDATA[
o Assign a moderator to do the following:
- distribute the functional specification
- schedule the session
- lead the session
- ensure errors are corrected
]]>
This person must be a competent designer but not the designer.
<![CDATA[
o Assemble the group with the following functions.
- testing
- programmers
- product marketing
- designer
- documentation (as needed)
- end user (as needed)
]]>
This activity will work best if the requirements are written in
an active tense. This activity requires nouns and verbs that
clearly demonstrate requirements.
The initial proposal may be included in the specification to
identify key objects from the overview perspective. Sometimes
design can be driven from top down.
The lower level functions may already be well defined. This may
lend itself to a bottom up design approach. This walkthrough
allows the team to gain experience proving out various approaches.
The moderator distributes the functional specification several
days before the walkthrough. The group should come after having
read and become familiar with the specification.
If desired, the group can focus on an area at a time and come with
CRC cards developed for review. A CRC card represents the following
preparation:
<![CDATA[
1- Circle nouns (Class of object)
2- Underline verbs (Responsiblities for an object)
3- Identify relationships (Collaborators)
]]>
Place them on 3 by 5 cards. In a group they can be marked on large
8.5 by 11 cards and displayed as part of the role play.
<![CDATA[
Class: editor (name of an object)
Responsibility: Collaborator:
- reads file
- writes file
- updates file
]]>
<![CDATA[
i.e. CRC cards
class / responsibility / collaborators
a class is the name of the object (nouns)
a responsibility (verbs) suggests the objects behavior
a collaborator are classes that interact
e.g. identify objects as nouns (circle)
identify responsibilities of nouns (verbs)
create a set of CRC cards
assign out players for each card
pass tokens around to roll play from object to object
fill in the missing pieces during role play
allow parallel paths to be tested out as well
]]>
This activity may spin off a set of questions iterating back
to the functional specification. The wording of the specification
may be changed to clarify the actual relationships found. The
wording may change to reflect more of the responsibility driven
design.
The designer should assemble the identified CRC objects into well
defined interfaces for the programming effort. The interface
should include at a minimum class and method names.
The moderator should redirect future design efforts in smaller
pieces if the whole is too much for one session. Certain pieces
as they are designed should become a black box for future walk
throughs.
Management issues and management reporting do not belong in walk
through sessions. The programmer should not feel uneasy about
looking openly at the specifications. If statistics are gathered
from session to session, they should be gathered as a collective
group over a period of time.
Organizations report:
<![CDATA[
number of objects per hour is typical
Optimal time to be 1-2 hours
Exposure to the overview benefits the group
Identifies objects that reflect a "real life" model
Interfaces can be exercised within a model
]]>