Rules and processes
elicitation is an ongoing activity throughout the whole duration of the project. Constant collaboration with the stakeholder is critical.
They will change their
minds as the project proceeds and that is perfectly fine.
Discover Rules from Subject Matter Experts
The rules discovery workshop is a powerful technique for
eliciting rules. It gathers all the key subject matter experts together for a short but intensely focused period.
The use of an outside facilitator experienced in requirements management can ensure the success of the workshop.
Brainstorming is the most efficient techniques used during the sessions.
Brainstorming involves both idea generation and idea reduction. The most creative,
innovative ideas often result from combining, seemingly unrelated ideas. Various voting techniques may be used to
prioritize the ideas created.
Allow for human behavior but control the following points:
-
Do not attack other participants
-
Do not come back late from a break: the sessions are short, so there
should be plenty of time for other activities during the day.
-
Avoid any domineering position
Some suggestions to improve the process:
-
Facilitator keeps a timer for all breaks and
fines anyone that is late, everyone gets one free pass
-
Facilitator encourages everyone to use
5-minute position statement
-
In case of long discussion without reaching
firm conclusion or agreement it is good to use the business concerns to drive the elicitation
-
If the rule is not clear this is good
practice to prototype it.
-
Use concrete scenario to illustrate some
rules. It will prepare for the tests.
In the case of a use case oriented roadmap the
analyst team will start from the use case or business process map and may ask the following standard elicitation
questions like:
Input DocumentType
|
Questions
|
Impacted Artifacts
|
-
Use case
-
Business process map
|
-
What happen on this business
activity?
-
What is the input information of
this activity?
-
What is the output ?
-
What kind of validation the user
is doing on this process step?
-
How
do we check that …?
-
What is happening in case of error
or exceptions?
-
Who is taking the final
decision?
|
|
|
|
|
|
|
|
Between
sessions, try to make some rule analysis to verify that business terms are well defined and the rules make sense and do
not have logical conflict. Log all the questions related to this analysis in a issue tracking document.
Discover Rules from Documentation
When they exist, precisely written business policy documents prove an excellent source of information for rule
elicitation. The advantage of a "company certified" policy document is that it is not biased by the
individual practice of a subject matter expert. In any case, the elicitation work performed from a document
should of course be corroborated by a subject matter expert, and usually takes frequent interaction with the SME to get
some explanation on a rule or a term that might be unclear or ambiguous.
It
is recommended to:
-
Get
an exhaustive list of the business events under scope and log them in a table
-
Get
the activities, tasks, processes that support the processing of those business events
-
Get
the business motivation behind the rules
-
Try
to extract the object model under scope, the domain values, etc...
We
should still apply agile modeling by involving the SME to get feedback on the findings, assumptions and
issues. Use simple diagrams to communicate with the project stakeholders.
|