[usage-centered] Re: Documenting Business Requirements thru
- We had to struggle with the same problem.
The way we solved it was somewhat outside of essential models. The development
team has repeatedly met with the business analysts representing the customer,
and systematically reviewed each requirement from their list. Each requirement
was clarified and expanded to make sure that everybody agreed on its meaning.
Follow up questions were assigned and researched. We recorded clarifications
for each requirement in a document, which had become our tracibility tool.
After we completed use cases and validated them with the user representatives,
we mapped them to the related requirements. These mappings were used in the
construction of the content model. Looking at a use case and all related
requirements helped us to identify almost all necessary materials and tools for
each interaction context. In some cases the individual data elements were
unknown, so we identified meaningful aggregations with the caveat that we will
break them down in the design phase. After creating all necessary contexts we
mapped them onto the requirements/use cases matrix to maintain tracibility.
When presenting to our users I showed the navigation map and explained the
overall organization of the interface and logic behind the key decisions. Then
I went through the map explaining the interaction and showing content schematics
of individual interaction spaces.
They seemed to be satisfied that each of their requirements was mapped onto one
or many use cases and was partially visible in the content model.
Another assumption that we agreed on was that we will minimize the amount of
pure business logic in the interface, which moved some of the business
requirements into process and rule design.
Hope this helps.
______________________________ Reply Separator _________________________________
Subject: [usage-centered] Documenting Business Requirements thru UCD
Author: tnunes@... at Internet
Date: 11/23/99 7:05 PM
Hello everyone. I am a new member to this group. I look forward to
sharing some great ideas with you all.
My question is: Through Use Cases or any other UCD models, how do you
capture the detailed business requirements? I have just completed the
first draft of essential use cases (as defined by Constantine &
Lockwood, whose site directed me to this group) and am preparing to
review them with the business users. I am anticipating comments like,
"Yes, that is how the system would be used, but I can't tell from these
use cases if you've understood all the requirements." I am speaking of
requirements such as: If option A is chosen, then information XYZ is
required. How are the business rules and edits captured? Do they
belong in the use case, or should they be written in a supporting
document? Any suggestions would be appreciated.
-- Talk to your group with your own voice!
- Your coupling of requirements with use cases and content models, then
feeding them back to the users, is very sophisticated. Driving the content
model from use cases bundled with the related requirements is recommended
practice that should have been in our book.
I will also underscore the value of using the navigation map for feedback
and validation with users. On a recent crunch-mode Web-application project,
we discovered the same ploy, which proved extremely valuable considering
that we had to shortcut the content model and go right to visual and
--Larry Constantine <www.foruse.com>