В теме 6 ответов, и 3 участника, последнее обновление сделано пользователем 
Denis Syropushchinsky 9 г назад.
-
Сообщения
-
Привет! Я работаю аналитиком в области, где нужно уделять большое внимание требованиям к пользовательскому вводу данных на форме. Моя область интересов — как сделать документацию более компактной без потери полноты требований.
Стандарт оформления требований в нашей компании жестко не регламентирован, и я имею возможность менять способы представления информации. Требованиями ко вводу пользуется дизайнер, тестировщик и разработчик. И их же смотрит владелец требований — для согласования.
А теперь к цели сообщения: кто может поделиться своими способами оформления требований ко вводу данных? Или готовыми методологиями? Или просто ссылками, мыслями и ключевыми словами для гугления на этот счет?:)
В аттаче — пример того, как это делаю я.
Что мне не нравится в моем способе:
1.Столбец «Требования» превращает таблицу в простыню текста.
2. В столбце «Требования» есть однотипные данные, которые хорошо бы сделать отдельными столбцами, но в таком случае остальные столбцы будут очень узкими и нечитабельными, перенос на переносе)
3. Против разбивки таблицы на разные части команда возражала, т.к. они хотят «все в одном месте».
Была также мысль в требованиях только перечислять названия полей, а вот нюансы выносить в Приложение. Но я это еще не опробовала, фидбека нет)
Прошу поделиться мнениями и опытом)
Если исходить из постановки вопроса, то не так уж и много вариантов сделать информацию компактнее, не жертвуя полнотой: избавиться от дубликатов или писать меньше слов :)По аттачу — вариантов море, т.к. проблема, если я правильно понял, простая: сделать столбцы примерно одинаковыми по объему заполняемых данных.
- Объедините столбцы до в один / несколько. Например, MIN/MAX значения.
- Оформляйте таблицы в Landscape режиме. Больше опций по изменению ширины таблиц будет.
- Разбейте столбец Требования на более типовые столбцы, как и предыдущие: например, Обязательность, Источник данных, Поведение, Допустимые значения и т.п. Если их получается много, то можно либо объединить, либо переходить опять-таки в Landscape.
- Источники данных вынесите в глоссарий данных, а тут просто укажите гиперссылку на соотв. место.
В дополнение:
Я не знаю контекста, поэтому не гарантирую корректность моих утверждений, но так, на всякий случай. При буквенно-символьном формате вводимых данных, актуально ли иметь мин/макс значения, как, например, 1? Имхо, одно другому противоречит. Требование в п. 2 вообще нужно? Что дополнительного оно несет с т.зр. информации? Об автокомплите вы уже сказали, а если источник данных для системы — только ее БД, то и какой смысл писать это в каждом поле? Далее, то, что в 3 — это, вероятно, общее требование для всех ваших элементов автокомплит (предположение), а следовательно и лучше выносить такие требования в описание свойств некого общего реюзабельного элемента управления. То, что в пункте 4 — не место ли этому в Типе данных? А то сходная информация разбивается между разными колонками.
Спасибо.- Объедините столбцы до в один / несколько. Например, MIN/MAX значения.
Да, это применю.
- Оформляйте таблицы в Landscape режиме. Больше опций по изменению ширины таблиц будет.
Это пробовала, тогда страдает остальная часть документа. Либо это вопрос моего вкуса, мне кажется, что прочий текст ( который не таблица требований ко вводу) «расползается» в ширину, теряется фокус при чтении. Это субъективно, конечно.
- Разбейте столбец Требования на более типовые столбцы, как и предыдущие: например, Обязательность, Источник данных, Поведение, Допустимые значения и т.п. Если их получается много, то можно либо объединить, либо переходить опять-таки в Landscape.
Изначально в шаблоне форматно-логического контроля они примерно так и были разбиты, я и так уже объединила, и получился как раз столбец «Требования» :)
- Источники данных вынесите в глоссарий данных, а тут просто укажите гиперссылку на соотв. место.
Тут возвращаемся к вопросу «всё в одном месте». И еще не поняла, почему источники данных — в Глоссарий, если это подробность реализации, а не термин или сокращение? Значения для автокомплита могут быть хардкодом, могут храниться в БД, могут получаться запросом из внешней системы. Это заодно к вопросу ниже, зачем нужно требование 2. Зачем это нужно — например, чтобы знать, каким образом вносить изменения.
При буквенно-символьном формате вводимых данных, актуально ли иметь мин/макс значения, как, например, 1? Имхо, одно другому противоречит.
Пример — юридическое лицо вводит свои ИНН,КПП и прочее. Это критичные данные, но число символов у них — стандартизированное.
Общее требование для всех ваших элементов автокомплит (предположение), а следовательно и лучше выносить такие требования в описание свойств некого общего реюзабельного элемента управления.
Тоже испробую) Правда, это будет выглядеть как «Общие свойства + отличия для данного автокомплита»,т.к.отличия в моем случае все-таки бывают.
То, что в пункте 4 — не место ли этому в Типе данных? А то сходная информация разбивается между разными колонками.
Не поняла вопрос. Столбец 4- это значение по умолчанию, которое отображается в данном поле при загрузке страницы.
Это пробовала, тогда страдает остальная часть документа. — Можно ведь только часть документа в таком формате сделать.И еще не поняла, почему источники данных — в Глоссарий, если это подробность реализации, а не термин или сокращение? — Это глоссарий данных, не терминов. Рекомендую почитать, например, у Вигерса, что это за вид требований.
Это критичные данные, но число символов у них — стандартизированное. — Так, я может перепутал, только сейчас дошло… Это минимальное количество символов или минимальное значение для числовых данных? В общем, тут можно порассуждать, т.к. что-то тут явно нарушено логически.
Столбец 4- это значение по умолчанию, которое отображается в данном поле при загрузке страницы. — Я про пункт 4 в столбце Требования.
А как вы оформляете такие требования?)Это глоссарий данных, не терминов. Рекомендую почитать, например, у Вигерса, что это за вид требований.
Почитала, это и в отчественном стандарте есть) Это опять же влечет за собой как минимум дополнительный раздел, или дополнительный документ. Но идея ясна, да.
Однако я надеялась еще услышать про принципиально другие подходы к описанию таких требований.А как вы оформляете такие требования?)
Приблизительно так и оформляем.
Настоятельно рекомендую использовать «Словарь данных/ Data Dictionary». Иначе вы начинаете множить одинаковые описания по всем(у) документу (ам). В результате описания начинают отличаться, их трудно сравнить, в них появляются расхождения (которые потом надо разделить на ошибки/»так и надо».
Поползновения «хотим всё в одном месте» — пресекать.
По поводу читаемости — это всё удобнее хранить в Экселе. Но есть свои минусы — ухудшается читаемость для команды. Поэтому ищите золотую середину.
Вы должны авторизироваться для ответа в этой теме.
