Requirement management (rus)

Как удобнее описывать справочники

Справочники есть в любой системе. Они бывают системные, бывают пользовательские, но они есть и это факт.

Справочник – простая таблица, содержащая список вариантов значений какого-либо параметра системы.

Справочники предназначены для заполнения полей системы посредством подбора значений из фиксированного перечня. Все записи справочника уникальны, то есть как минимум одно поле обязательно для заполнения.

Каждый справочник представляет собой таблицу, иногда грид редактируемый, иногда нет. Тем не менее, как правило, все справочники выглядят одинаково в рамках одной системы и имеют идентичные функции.

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

Наименование справочника
Страна
Тип населенного пункта
Населенный пункт (связан со страной и с субъектом)

Справочник не всегда открыт на редактирование и иногда использует данные других справочников. Как это описать, не заворачиваясь с интерфейсом, единообразно и прочее.

Я задался этим вопросом и постараюсь на него ответить.

Описание справочника

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

Вторым делом определяем какие он будет содержать поля и таблицы.

Для этого нам потребуется колонка для номера поля, названия, типа поля, его свойств. С названием всё предельно понятно, какие бывают типы в принципе тоже, вот один из вариантов:

  1. Текст
  2. Текст с гиперссылкой
  3. Список – Текст (выпадающий список)
  4. Число целое
  5. Число дробное
  6. Дата
  7. Логическое (да/нет)
  8. Файл
  9. Комбо-бокс
  10. Автоматически рассчитывается
  11. Текстовое поле ввода
  12. Текстовое поле ввода (количество строк)

В скобках можно указать количество символов.

  1. Общие свойства поля
  2. Редактируемое или нет
  3. Значение по умолчанию
  4. Обязательное или нет
  5. Уникальное и в рамках чего (пример: в рамках привилегированных акций или вообще всех)
  6. Выбор из списка (либо перечисляются доступные значения, либо дается ссылка на другой справочник)
  7. Хранение истории

Дополнительные свойства

Можно выводить как в одной, так и во множестве колонок. Я встречал как таблицы описания полей как из 4 колонок, так и из 30 (см ниже, по причинам конфиденциальности оно нечитабельно).

  1. Автоматический расчет
  2. Проверки (ограничения на ввод)
  3. Переводы на другие языки
  4. Сложные зависимости для отображения
  5. Ролевой доступ

Фильтрация

Далее нам необходима фильтрация (или поиски). Там мы описываем какие поля у нас есть и какие в них доступны значения для поиска.

Примечание

Отдельно следует выводить подчиненные таблицы, и выделять поля, выводимые в одну строку.

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

Сформулированные правила могут быть применимы ко всей системе и даже более – стать внутренним стандартом компании. По причине конфиденциальности я не могу показать готовый документ или регламент, тем не менее, я бы рекомендовал задуматься об этом в самой компании или вам, аналитику. Это, несомненно, принесет вам дивиденды и весомый опыт.

Advertisements
Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s