BoatmansHome: Заметки/ Stop The Magic ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Во-первых, речь идет о системных функциональных требованиях вида «система должна (что-то делать)".
Это может применяться в сценариях вариантов использования уровня моря, в описании функций в техническом проекте. Можно применять при описании требований к функционированию в ТЗ по ГОСТ 34.602. И в других документах и артефактах, отражающих функциональные требования.
Во-вторых, мы помним из определения автоматизированной системы и информационной системы, равно, как и программной системы, что назначение их всех – обработка данных.


Классификация функций

Суть в том, что у информационной системы всего 5 видов функций:
* ввод данных;
* вывод данных;
* обработка данных;
* хранение данных;
* транспортировка данных.


Однако часто в системные требования попадает реальная магия.
Например «Система разрешает», «Система оформляет», «Система контролирует», «Система принимает решение», «Система утверждает».
Все вышеперечисленные формулировки нагоняют магической жути своей неконкретностью. Каждый раз, когда не до конца ясно, как система это делает в требованиях появляется новый глагол без дополнительных пояснений. И это не пустое ворчание.
Дело в том, что по пяти видам функций ясно, что
* При указании функций ввода и вывода есть возможность привязаться к конкретному интерфейсному элементу или каналу;
* При указании функции хранения есть возможность указать конкретные элементы логической схемы данных, в которых происходит хранение;
* при указании функции транспортировки есть возможность указать каналы, протоколы, форматы передачи;
* при указании функции обработки есть возможность указать алгоритм.


При указании любой функции мы должны идентифицировать ее, задав входы и выходы.


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


В развитие этой мысли у нас появляются 2 техники работы с требованиями.

  1. Проверка функциональных требований по классификации функций
  2. Выработка метаязыка для описания требований

Проверка требований

Каждый раз, когда мы видим описание функции, спрашиваем себя, какой вид функции сейчас описывается: ввод, вывод, хранение, обработка или передача.
Вне зависимости от вида функции уточняем, ясны ли нам входы и выходы – какие объекты в каких состояниях функция берет и отдает.
Определение вида функции помогает нам с входами и выходами, так как сразу локализуются возможные места, где мы можем обнаружить входные и выходные данные – это или внутренняя память системы (сумма всех ее запоминающих устройств, при описании системы в целом, выступающая как единое хранилище) или интерфейсные элементы ввода/вывода или каналы передачи.
При этом явное выделение функций обработки дает нам проверить, ясен ли алгоритм, не нужно ли его довыяснить и/или описать.
Если нужны уточнения, мы можем открыть вопросы или сразу уточнить в привязке к данной функции элементы интерфейсных решений, элементы логической схемы данных системы, алгоритмы обработки или протоколы и каналы передачи данных, добавляя в требования соответствующие решения или открытые вопросы.

Метаязык функциональных требований

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

Подчеркивания в предыдущем предложении появились в ответ на подозрения коллег в категоричности. Писать можно как угодно. Но чем меньше терминов вводится в технический текст, тем проще с ним работать всем. При этом выбранная система терминов распространяется на данный проект. В следующем проекте термины можно перевыбрать
Еще важно понимать, что любой текст трактуется в контексте (http://boatmanshome.ru/cgi-bin/page.pl?21dev_001_002.page#A6). При специфической аудитории с близким контекстом, с собственным устоявшимся языком общения или с какими-то еще ограничениями на применение тех или иных терминов рекомендации этого раздела надо применять осторожно. Так же бывает необходимо записать требования не конкретно, а, наоборот, расплывчато, хоть нам это чаще всего и не нравится.

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

Так, например, если речь идет о современном пользовательском интерфейсе, мы можем иметь дело с вводом данных с клавиатуры (inputbox, textbox) «система позволяет ввести/пользователь вводит», выбором из списка вариантов (checklist, listbox, menu) «система позволяет выбрать/пользователь ввыбирает», отображение сообщения с выбором варианта реакции (messagebox) «система сообщает» и т.п. Для вывода может быть отображение текста, отображение данных в таблице с возможностью прокрутки и сортировки (grid), отображение сообщения с одной кнопкой «ОК» и т.п.
Если есть принтер или сканер штрих-кода и другие устройства ввода-вывода, на работу с ними тоже нужно зарезервировать по словосочетанию: «система распечатывает», «система вводит код со сканера» и т.п..

При разработке требований надо выписать или держать в гоолове все возможные интерфейсные решения для этой системы и каждый раз использовать одну и ту же формулировку для их описания.


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


 
Файлов нет.[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]