С частью 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 специалистами ссылка.
.