С частью 1 можно ознакомиться, перейдя по ссылке
Рекомендации по проектированию спецификаций требований с примерами
То, о чем не говорят, каждый понимает по-своему
Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.
Готовим читателей к знакомству со спецификациями
Итак, с чего может начинаться знакомство команды разработки, с представленными требованиями? Непременно с презентации аналитиком своего творения, будущим исполнителям. Для обоих сторон очень важно, насколько успешно будет установлен первый контакт и преодолен барьер вхождения в новый процесс. Но часто, по ряду причин очно это сделать невозможно или проблематично. Поэтому хорошим тоном будет включение в начало документа раздела, с кратким обзором его структуры и представления информации, а также разъяснением, как правильно и эффективно ее использовать.
Пример обзора документа:
Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Выглядеть это может вот так:
При разработке последующих артефактов документа, в них должны быть проставлены ссылки на Потребности пользователей зафиксированные в рассмотренном выше разделе (благо каждая потребность имеет свой идентификатор). Таким образом, мы сможем убедиться, что все цели, которые должен удовлетворить целевой продукт проекта, могут быть выполнены в ходе его реализации.
Визуализируем компонентную структуру целевого продукта
Основная проблема масштабных проектов – необходимость использования большого количества компонентов. Этот факт может значительно затруднять единое представление в воображении членов команды всей картины продукта целиком. Для борьбы с этим злом, я стараюсь в начало документа добавить раздел, описывающий общую компонентную архитектуру целевого продукта. Этот раздел помогает представить на одном (или нескольких) изображениях все основные узловые элементы целевого продукта, а также ознакомиться с описанием способов и режимов взаимодействия их между собой.
В своей работе «Унифицированный процесс разработки ПО» [5] Айвар Якобсон термину Архитектура дал такое определение: «это представление всего проекта с выделением важных характеристик и затушевыванием деталей».
На место центрального элемента этого раздела, на мой взгляд, идеально подходит нотация диаграммы архитектуры. Этот вид представления похож на каноническую диаграмму компонентов, но выглядит более наглядно и доступен для понимания широкому кругу специалистов.
Ниже приведен фрагмент включения в требования раздела с описанием архитектуры системы.
Такие большие схематичные рисунки желательно сопровождать текстом, помогающим читателям разобраться в них.
Такое представление особенно полезно, когда в проекте участвует несколько команд. Они могут четко определить точки (интерфейсы) соприкосновения компонентов системы, а также своего (команд) взаимодействия. Понимание общей модели позволит на ранних стадиях избежать «провисания» ответственности исполнителей на смежных участках работ.
Если в документе рассматривается не вся система, а только ее часть, то эту часть можно выделить на диаграмме цветом. Таким образом, в различных документах может повторяться одна и та же диаграмма компонентной архитектуры, но с выделенными цветом разными частями (компонентами).
Представим целевой продукт в динамике
Когда мы познакомили аудиторию с общими потребностями заказчика и визуализировали архитектуру разрабатываемого продукта, читатель уже имеет представление о его основных функциях и структуре построения системы в целом. Теперь можно перейти к более детальному знакомству с основными сценариями ее использования. В ГОСТ-34.602-89 [4] подобный раздел называется «требования к функциям (задачам), выполняемым системой».
Часто, при оформлении подобных разделов, в требованиях используют диаграммы: Вариантов использования (UseCase) или описания Бизнес-процессов (BPMN), или алгоритмов выполнения (Activity), или функциональных моделей IDEF0 и т.д. Все эти виды диаграмм незаменимы на этапе проектирования, определения рамок проекта и т.п. Но из моего опыта, они малоприменимы для программистов. С точки зрения разработчиков, которым предназначен данный документ, гораздо комфортнее работать именно со сценариями использования спроектированной системы, представленного в виде структурированного текстового описания. Резюмируя все вышесказанное в этом абзаце отмечу: не перегружайте этот раздел информацией, которой никто не воспользуется, а будет каждый раз пролистывать мимо, чтобы добраться до нужного раздела.
Ниже представлен вариант описания сценариев, который я часто использую на практике. Основные критерии при разработке этого подхода, были таковы:
- Участники, работающие с описанием, не имеют специальной подготовки и не могут свободно читать нотации;
- Читатели по описанию должны четко и полно представить себе все действия, которые будут выполняться пользователями при помощи целевого продукта (модуля, подсистемы и т.п.);
- Необходимо структурировать и представить информацию, используя приемы лучших практик описания процессов;
Такие сценарии помогают разработчикам в дальнейшем, в процессе реализации статических объектов и компонентов системы, оперативно уточнить динамику их взаимодействия. Поэтому дальше, в описании Сущностей, Форм, Процедур и т.п. обязательно должны использоваться ссылки на сценарии, в которых они задействованы (благо сценарии, как и все другие объекты спецификаций, у нас имеют идентификаторы).
Эти же сценарии могут послужить основой для работы еще одной группы потребителей требований – QA специалистов, поскольку они очень близки по форме к сценариям тестирования.
ОПРЕДЕЛЯЕМ СОСТАВ И ФОРМУ СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ
Спецификации требований – это не решебник с ответами, а последовательный план действий
Теперь, когда все ознакомительные разделы подготовлены, можно переходить к формированию ключевой части документа – спецификациям функциональных требований, которые послужат отправной точкой для формирования заданий разработчикам.
Спецификации должны быть сгруппированы и хорошо структурированы в виде блоков информации. Блок самого нижнего уровня, должен представлять из себя атомарное требование, готовое для передачи его разработчику в виде задачи. Поэтому, каждая Спецификация должна содержать информацию, достаточную для того, чтобы разработчик смог однозначно и полно реализовать требование, не обращаясь за разъяснениями и уточнениями к автору. Такой подход позволит менеджеру проекта пробежавшись по спецификациям, не особо напрягаясь, сформировать из них набор «заготовок» для составления подробного плана-графика проекта. Ну об этом позже.
Начнем с хранилища
Как мы договорились в процессе определения структуры и порядка следования спецификаций, этап реализации разработчиками требований должен начинаться с формирования хранилища данных. Поэтому, в своем варианте спецификаций, первый раздел я посвящаю этой теме. В начале раздела, для более полного понимания доменной модели, желательно привести общую структуру данных. Это можно сделать при помощи диаграммы классов, она довольно популярна и известна большинству ИТ специалистов. Изображение позволит разработчикам созерцать всю структуру разом. Следом необходимо детализировать спецификации для каждой отдельной Сущности, которая используется в модуле.
Ниже приведен пример спецификаций для рассматриваемого проекта:
Таким образом разработчикам, получившим подобные требования, остается только транслировать их в код по генерации объектов Базы данных (далее БД). Для выполнения подобных операций можно привлечь специалистов с невысокой квалификацией и сэкономить бюджет проекта.
Рекомендую разбивать модуль (систему) на подсистемы, чтобы в каждой из них читатель оперировал количеством реализуемых сущностей от 3 до 7. Это позволяет: во-первых, легче воспринимать материал, а во-вторых, одновременно вести разработку модуля — нескольким разработчикам (каждый реализует отдельную подсистему).
Похожий раздел есть в ГОСТ-34.602-89 [4] и называется он «Описание организации информационной базы».
От хранения данных шагнем к их отображению на визуальных формах
После описания всех Сущностей, которые необходимо реализовать в данном модуле (подсистеме), можно приступать к разработке визуальных форм. Требования к формам удобно оформлять в таком же стиле. При описании важно опираться на визуальные компоненты интерфейса пользователя, предоставляемые платформой, на которой ведется разработка. При описании форм необходимо указывать какие элементы БД, описанные в предыдущем разделе, используются для визуального представления атрибутов (благо они тоже имеют идентификаторы). А для того чтобы разработчики полнее представляли, что-же они разрабатывают и как это все будет шевелиться на экране, в описании формы следует упомянуть о сценариях в которых данная форма используется, не забыв указать ссылку.
Заметьте, что для сложных атрибутов (например, [UI1.2.2.a9]) в таблице сразу описаны ссылки на сущность, с которой он связан, ограничения для выборки данных, поля для отображения на форме, правила переходов по ссылкам на форме и т.д. Для каждого атрибута указано представление, соответствующее визуальным компонентам системы. При таком подробном и однозначном описании, разработчики могут легко реализовать требования к интерфейсу пользователя в установленные сроки с прогнозируемым качеством. Глубокая детализация также позволяет привлечь к работам менее квалифицированный персонал и помогает менеджеру проекта эффективно распределить задачи в команде, повышая рентабельность проекта в целом.
Наделим визуальные формы поведением
После того как специфицированы визуальные формы, можно приступать к программированию их поведения. Поэтому в следующем разделе я обычно представляю все процедуры, которые могут быть выполнены автоматически при обработке событий формы или инициированы пользователем при работе с элементами GUI (кнопки, меню и т.п.).
Для удобства использования, каждой Спецификации требования необходимо присвоить свой уникальный идентификатор. Эти идентификаторы могут быть применены в качестве ссылок, как в самих требованиях, так и в других артефактах проекта, в том числе на диаграммах. Вариант описания действий, в частности алгоритм формирования идентификатора, можно просмотреть в приведенном ниже примере требований.
Если в модуле используются сложные функции, предполагающие описание объемных алгоритмов, определение входящих и выходящих параметров, разработку дополнительной структуры хранения данных и т.д., то я включаю в документ отдельный раздел с требованиями к вспомогательным функциям. На него могут ссылаться спецификации, описывающие действия для форм, рассмотренные выше. Например, вспомогательную функцию удобно использовать, когда одна и та же базовая функция вызывается при событиях разных форм. Похожий раздел есть в ГОСТ-34.602-89 [4] и называется он «Описание алгоритма».
Ниже приведен пример подобного представления:
Дальше в документе опционально могут следовать разделы об: Отчетах, Периодических заданиях, Расширенном поиске и т.п. Эти пункты желательно заполнять с таким же уровнем детализации, как показано выше в примерах, указывая ссылки на используемые сущности, процедуры и т.п.
Позаботимся о безопасности
Еще один немаловажный раздел, который должен быть упомянут в документе для подобного рода систем, посвящен правам доступа. В нем идентифицируются Роли, приводится их описание, а дальше указываютсяя права доступа для этих ролей к объектам данных и элементам интерфейса пользователя.
Ниже приведен пример требований к подсистеме управления правами доступа:
Заметьте, в приведенном выше примере таблицы ролей, нет описания целей заинтересованных лиц и т.п. Эти подробности важны для аналитика на этапе формирования требований, но практически бесполезны для разработчиков. Следующим шагом, для удобства восприятия можно составить таблицы, в ячейках которых будут зафиксированы разрешенные действия для ролей, перечисленных в качестве столбцов, к имеющимся: процедурам, таблицам БД, элементам интерфейса пользователя и т.д., указанным в виде строк. А разрешенные действия можно обозначать например, в виде первых букв английских слов (C- Create, R-Read, W-Write и т.д.)
Похожий подраздел есть, например, в ГОСТ-34.602-89 [4] и называется он «требования к защите информации от несанкционированного доступа».
В заключительной части я покажу на примерах варианты эффективного использования подобных спецификаций требований, PM и QA специалистами.
[2] А. Коберн, «Современные методы описания функциональных требований», Лори, 2002, p. 288.
[3] У. Д. Леффингуэлл Дин, Принципы работы с требованиями к ПО, Вильямс, 2002, p. 448.
[4] ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
[5] Б. Г. Р. Д. Якобсон А., Унифицированный процесс разработки программного обеспечения, Питер, 2002, p. 496.
Автор: Алексей Радзишевский
