Оформление требований ко вводу данных




Главная   Форумы   Общие вопросы по работе с требованиями   Оформление требований ко вводу данных

В теме 6 ответов, и 3 участника, последнее обновление сделано пользователем Аватар (Denis Syropushchinsky) Denis Syropushchinsky 2 г назад.

Показано 7 ответов - от 1 до 7 (всего 7)
  • Автор
    Сообщения
  • 11.11.2015 в 12:37 # 17994
    Аватар (Anastacia Tchitchigina)
    Anastacia Tchitchigina
    Подписчик
    Привет! Я работаю аналитиком в области, где нужно уделять большое внимание требованиям к пользовательскому вводу  данных на форме. Моя область интересов — как сделать документацию более компактной без потери полноты требований.

    Стандарт оформления требований в нашей компании жестко не регламентирован, и я имею возможность менять способы представления информации. Требованиями ко вводу пользуется дизайнер, тестировщик и разработчик. И их же смотрит владелец требований —  для согласования.

    А теперь к цели сообщения: кто может поделиться своими способами оформления требований ко вводу данных? Или готовыми методологиями? Или просто ссылками, мыслями и ключевыми словами для гугления на этот счет?:)

    В аттаче — пример того, как это делаю я.

    Что мне не нравится в моем способе:

    1.Столбец «Требования» превращает таблицу в простыню текста.

    2. В столбце «Требования» есть однотипные данные, которые хорошо бы сделать отдельными столбцами, но в таком случае остальные столбцы будут очень узкими и нечитабельными, перенос на переносе)

    3. Против разбивки таблицы на разные части команда возражала, т.к. они хотят «все в одном месте».

    Была также мысль в требованиях только перечислять названия полей, а вот нюансы выносить в Приложение. Но я это еще не опробовала, фидбека нет)

    Прошу поделиться мнениями и опытом)

    Вложения:

    Вы должны войти, чтобы смотреть прикрепленные файлы.

    Поделиться:

    Цитировать

    11.11.2015 в 14:09 # 17996
    Если исходить из постановки вопроса, то не так уж и много вариантов сделать информацию компактнее, не жертвуя полнотой: избавиться от дубликатов или писать меньше слов :)

    По аттачу — вариантов море, т.к. проблема, если я правильно понял, простая: сделать столбцы примерно одинаковыми по объему заполняемых данных.

    - Объедините столбцы до в один / несколько. Например, MIN/MAX значения.

    - Оформляйте таблицы в Landscape режиме. Больше опций по изменению ширины таблиц будет.

    - Разбейте столбец Требования на более типовые столбцы, как и предыдущие: например, Обязательность, Источник данных, Поведение, Допустимые значения и т.п. Если их получается много, то можно либо объединить, либо переходить опять-таки в Landscape.

    - Источники данных вынесите в глоссарий данных, а тут просто укажите гиперссылку на соотв. место.

    В дополнение:

    Я не знаю контекста, поэтому не гарантирую корректность моих утверждений, но так, на всякий случай. При буквенно-символьном формате вводимых данных, актуально ли иметь мин/макс значения, как, например, 1? Имхо, одно другому противоречит. Требование в п. 2 вообще нужно? Что дополнительного оно несет с т.зр. информации? Об автокомплите вы уже сказали, а если источник данных для системы — только ее БД, то и какой смысл писать это в каждом поле? Далее, то, что в 3 — это, вероятно, общее требование для всех ваших элементов автокомплит (предположение), а следовательно и лучше выносить такие требования в описание свойств некого общего реюзабельного элемента управления. То, что в пункте 4 — не место ли этому в Типе данных? А то сходная информация разбивается между разными колонками.

    Поделиться:

    Цитировать

    11.11.2015 в 14:52 # 17997
    Аватар (Anastacia Tchitchigina)
    Anastacia Tchitchigina
    Подписчик
    Спасибо.

    - Объедините столбцы до в один / несколько. Например, MIN/MAX значения.

    Да, это применю.

    - Оформляйте таблицы в Landscape режиме. Больше опций по изменению ширины таблиц будет.

    Это пробовала, тогда страдает остальная часть документа. Либо это вопрос моего вкуса, мне кажется, что прочий текст ( который не таблица требований ко вводу) «расползается» в ширину, теряется фокус при чтении. Это субъективно, конечно.

    - Разбейте столбец Требования на более типовые столбцы, как и предыдущие: например, Обязательность, Источник данных, Поведение, Допустимые значения и т.п. Если их получается много, то можно либо объединить, либо переходить опять-таки в Landscape.

    Изначально в шаблоне форматно-логического контроля они примерно так и были разбиты, я и так уже объединила, и получился как раз столбец «Требования» :)

    - Источники данных вынесите в глоссарий данных, а тут просто укажите гиперссылку на соотв. место.

    Тут возвращаемся к вопросу «всё в одном месте». И еще не поняла, почему источники данных — в Глоссарий, если это подробность реализации, а не термин или сокращение? Значения для автокомплита могут быть хардкодом, могут храниться в БД, могут получаться запросом из внешней системы. Это заодно к вопросу ниже, зачем нужно требование 2. Зачем это нужно — например, чтобы знать, каким образом вносить изменения.

    При буквенно-символьном формате вводимых данных, актуально ли иметь мин/макс значения, как, например, 1? Имхо, одно другому противоречит.

    Пример — юридическое лицо вводит свои ИНН,КПП и прочее. Это критичные данные, но число символов у них — стандартизированное.

    Общее требование для всех ваших элементов автокомплит (предположение), а следовательно и лучше выносить такие требования в описание свойств некого общего реюзабельного элемента управления.

    Тоже испробую) Правда, это будет выглядеть как «Общие свойства + отличия для данного автокомплита»,т.к.отличия в моем случае все-таки бывают.

    То, что в пункте 4 — не место ли этому в Типе данных? А то сходная информация разбивается между разными колонками.

    Не поняла вопрос. Столбец 4- это значение по умолчанию, которое отображается в данном поле при загрузке страницы.

    Поделиться:

    Цитировать

    11.11.2015 в 16:37 # 17998
    Это пробовала, тогда страдает остальная часть документа. — Можно ведь только часть документа в таком формате сделать.

    И еще не поняла, почему источники данных — в Глоссарий, если это подробность реализации, а не термин или сокращение? — Это глоссарий данных, не терминов. Рекомендую почитать, например, у Вигерса, что это за вид требований.

    Это критичные данные, но число символов у них — стандартизированное. — Так, я может перепутал, только сейчас дошло… Это минимальное количество символов или минимальное значение для числовых данных? В общем, тут можно порассуждать, т.к. что-то тут явно нарушено логически.

    Столбец 4- это значение по умолчанию, которое отображается в данном поле при загрузке страницы. — Я про пункт 4 в столбце Требования.

     

     

     

    Поделиться:

    Цитировать

    12.11.2015 в 09:17 # 17999
    Аватар (Anastacia Tchitchigina)
    Anastacia Tchitchigina
    Подписчик
    А как вы оформляете такие требования?)
    Поделиться:

    Цитировать

    12.11.2015 в 09:25 # 18000
    Аватар (Anastacia Tchitchigina)
    Anastacia Tchitchigina
    Подписчик
    Это глоссарий данных, не терминов. Рекомендую почитать, например, у Вигерса, что это за вид требований.

    Почитала, это и в отчественном стандарте есть) Это опять же влечет за собой как минимум дополнительный раздел, или дополнительный документ. Но идея ясна, да.
    Однако я надеялась еще услышать про принципиально другие подходы к описанию таких требований.

    Поделиться:

    Цитировать

    18.11.2015 в 11:03 # 18009
    Аватар (Denis Syropushchinsky)
    Denis Syropushchinsky
    Подписчик

    А как вы оформляете такие требования?)

    Приблизительно так и оформляем.

    Настоятельно рекомендую использовать «Словарь данных/ Data Dictionary». Иначе вы начинаете множить одинаковые описания по всем(у) документу (ам). В результате описания начинают отличаться, их трудно сравнить, в них появляются расхождения (которые потом надо разделить на ошибки/»так и надо».

    Поползновения «хотим всё в одном месте» — пресекать.

    По поводу читаемости — это всё удобнее хранить в Экселе. Но есть свои минусы — ухудшается читаемость для команды. Поэтому ищите золотую середину.

    Поделиться:

    Цитировать

Показано 7 ответов - от 1 до 7 (всего 7)

Вы должны авторизироваться для ответа в этой теме.