| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Folk-
We ran
out of time during the telephone call to fully discuss the marking of
requirements. I would like to identify those requirements that are
specifically for FDD, those for TDD and those that apply to both. We
should also mark those requirements than are goals, optional, and those that are
required.
I have
read, created and implemented both well and poorly written requirement
documents. A poorly written document leaves the reader with sentences
that could or could not be a requirement. For example-
"A
good document shall be readable."
Question- how does one determine if the document is
"readable"? Clearly this is a goal, since it is not
quantifiable. But if the author (or requestor) immediately realizes the
ambiquity, there is time to rewrite the requirement to correctly reflect the
intention. If we wait to mark the requirements, we leave the door open to
rehash the discussion, after we thought the requirement document was
closed.
I
believe each author of a requirement should mark the requirement when it's
proposed.
alan
chickinsky
|