A course I attended once, called Extended Relational Design (TM), actually promoted drawing up tables during requirements gathering. But these weren't table designs - they were actual tables of populated sample data - with the customer. This had a strategic purpose, though: through careful questioning, the real relationships (repeating groups, true primary keys, foreign keys, etc.) were discovered. Customers may understand this process using concrete data more readily than the entity-relationship diagrams and UML that may go into a formal specification. This resonates with Crystal's point about using current forms and reports as intelligence. Even here, though, questions are worthwhile.
In a school where I worked, our new manager created a paper form to keep a log of individual incidents related to a student. At the top, in the header area above the grid of log entries, was a line for "Teacher". However, all our classes were "team taught" - every student had more than one teacher each week. This manager clearly didn't understand how we worked, or hadn't thought properly about her form design. (Years later, this form exists unaltered, by the way!). Current practice isn't always best practice.
David
Posted by: david@powell-au.net
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (17) |
Tidak ada komentar:
Posting Komentar