Проектирование Информационных систем. Часть 10. Разработка требований 10.2. Формирование спецификаций требований

Содержание курса

• ВВЕДЕНИЕ

• Введение в процесс формирования требований

• Инфраструктура (ландшафт) для организации проектной деятельности

• Управление целями заинтересованных лиц

• Формализация потребностей заказчика

• Выявление функции системы. 1.Теория систем Часть 1

• Выявление функции системы. 2. Моделирование сервисов

• Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity

• Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.

• Разработка логической структуры данных. 1. Применение UML Class diagram. Приемы и подходы проектирования

• Разработка логической структуры данных. 2. Паттерны проектирования применительно к структуре данных.

• Моделирование поведения целевой системы. 1. Теория систем Часть 2

• Моделирование поведения целевой системы. 2. Поведенческие диаграммы UML

• Моделирование поведения целевой системы. 3. Моделирование процессов управления

• Разработка требований на создание целевой ИС. 1. Правила формирования требований

• Разработка требований на создание целевой ИС. 2. Формирование Спецификаций требований

• Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта

• Организация процессов проектирования в производстве ИТ-продукта

5.    Формирование спецификаций требований на создание целевого продукта

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

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

Для чего это необходимо делать?

Все полученные артефакты складываются в стройную и полную модель прототипа целевого продукта только в реальности проектировщиков. Если же взглянуть на результат проектирования отстраненным взглядом команды, которой предстоит воплощать эту модель в коде, то окажется, что в общей картине не хватает множества разъяснений, стыковок, структурированности, последовательности исполнения и тому подобного.

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

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

В конечном счете нам необходимо продумать и зафиксировать:

• Состав спецификации требований;

• Достаточный уровень детализации;

• Форму и порядок представления информации в них.

Такой подход позволит нам:

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

• Избавить членов команды от бесполезной траты время на изучение артефактов, которые не существенны для них, при выполнении работ в проекте

• Регламентировать деятельность команды и четко тарифицировать работы с точки зрения ресурсоемкости

Решение указанных проблем, даст возможность команде поставить процесс разработки ПО на поток и построить технологическую линию по производству ИТ-продуктов.

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

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

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

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

•    Менеджеру проекта важно — насколько удобно он сможет «нарезать» спецификации на атомарные задачи для остальных членов команды, группировать задачи в вехи (этапы) проекта и согласовывать на каждом этапе с заказчиков прирост функциональности ИТ-продукта.

•    Специалистам по качеству важно — насколько удобно им будет формировать по требованиям – сценарии тестирования, карты приемки и т.п.

•    Заказчика же волнует, насколько точно он сможет на всех стадиях реализации представлять себе состояние целевого продукта и его функциональности.

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

Спецификация требований (SRS — Software Requirements Specification) — это документ, в котором формально и полно описаны требования к разрабатываемой системе или продукту. Он служит основой для планирования, проектирования, разработки, тестирования и сопровождения ПО.

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

Для этого необходимо ответить на вопрос: чем же оперируют разработчики, создавая конечный продукт? Поскольку мы в рамках нашего курса не можем рассмотреть все многообразие подходов и технологий, остановимся для примера, на варианте разработки ПО на базе некой технологической платформы с использованием СУБД. В этом случае целевую систему можно представить в виде набора компонентов, постоянное слаженное взаимодействие которых и приводит к “эффекту работающей программы”.

 Например, это может быть:

• Хранилище данных

• Подсистема сценарного языка высокого уровня

• Система формирования отчетов

• Подсистема запуска периодических заданий

• Движок Workflow для интерпретации бизнес-процессов

• Подсистема генерации пользовательского интерфейса

• Подсистема управления правами доступа

• И так далее

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

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

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

Для реализации хранилищ разработчикам, например, может понадобиться информация о:

• типе бизнес-объекта, чтобы платформа смога разложить его на таблицы в хранилище;

• типах атрибутов, для генерации дополнительных свойств полей в таблицах;

• связях бизнес-объектов для генерации вторичных ключей;

• фильтруемых полях, для генерации индексов;  

• возможных состояниях и действиях перехода, для генерации методов и триггеров, поддерживающих поведение;

• и прочее.

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

Далее, заложив фундамент информационной системы – хранилище информации, мы можем реализовать представление этой информации на экранных формах пользователя.

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

Получив отображение данных на экране, появляется возможность реализовать реакцию системы на действия производимые пользователем, по заполнению атрибутов, выбору меню, нажатию кнопок в виде выполнения процедур и функций. Поэтому в разделе с описанием визуальных форм могут быть представлены варианты разных моделей формы, например, соответствующих определенным состояниям бизнес-объекта на каждом этапе Жизненного цикла. Могут быть описаны алгоритмы и процедуры, применимые к реагированию на события, связанные с интерфейсом пользователя. Но в таком случае такая стилистика должна поддерживаться для всего состава спецификаций, согласно правилу R39 — Руководство по стилю.

Если в платформе используется движок бизнес-процессов, то в спецификациях явно должен быть раздел с описанием процессов, возможно с использованием диаграммами BPMN или других нотаций.

Реализовав же функции и процедуры можно подключать их к подсистеме периодического вызова по расписанию, если в этом есть необходимость.

Когда построена система хранения данных и организовано взаимодействие пользователя с системой, можно формировать различные представления информации в виде отчетов.

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

Таким образом команда проектирования и команда разработки договаривается о составе, порядке представления и уровне детализации спецификаций требований.

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

С критически важными разделами требований разобрались. Теперь рассмотрим, что же еще необходимо включить в состав.

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

Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа как обязательных, желательно включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 он называется «назначение и цели создания (развития) системы».

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

Такое представление особенно полезно, когда в проекте участвует несколько команд. Они могут четко определить точки (интерфейсы) соприкосновения компонентов системы, а также своего (команд) взаимодействия. Понимание общей модели позволит на ранних стадиях избежать “провисания” ответственности исполнителей на смежных участках работ.

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

Когда мы познакомили аудиторию с общими потребностями заказчика и визуализировали архитектуру разрабатываемого продукта, читатель уже имеет представление о его основных функциях и структуре построения системы в целом. Теперь можно перейти к более детальному знакомству с основными сценариями ее использования. В ГОСТ-34.602-89 подобный раздел называется «требования к функциям (задачам), выполняемым системой».
Часто, при оформлении подобных разделов, аналитики используют диаграммы: Вариантов использования (UseCase) или описания Бизнес-процессов (BPMN), или алгоритмов выполнения (Activity), или функциональных моделей в нотации IDEF0 и т.п. Все эти виды диаграмм незаменимы на этапе проектирования, определения рамок проекта и т.п. Но из моего опыта, слишком далеки они от большинства членов команды.

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

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

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

Важность этого раздела для специалистов по качеству трудно переоценить.

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

А для этого спецификации должны быть сгруппированы и хорошо структурированы в виде блоков информации, в соответствии с правилом R42 — Структурированные наборы. Блок самого нижнего уровня, должен представлять из себя атомарное требование, готовое для передачи его разработчику в виде задачи (соответствие свойству C5 – Простота). Поэтому, каждая Спецификация должна содержать информацию, достаточную для того, чтобы разработчик смог однозначно и полно реализовать требование, не обращаясь за разъяснениями и уточнениями к автору (соответствие свойству C4 – Полнота). Такой подход позволит менеджеру проекта пробежавшись по спецификациям, не особо напрягаясь, сформировать из них набор «заготовок» для составления подробного плана-графика проекта. Ну об этом чуть позже.

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

Поэтому, в своем варианте спецификаций, первый раздел основного блока я посвящаю этой теме. В начале раздела, для более полного понимания доменной модели, желательно привести общую структуру данных. Это можно сделать при помощи диаграммы классов, она довольно популярна и известна большинству ИТ специалистов. Изображение позволит разработчикам созерцать всю структуру данных модуля в целом. Следом необходимо детализировать спецификации для каждой отдельной Сущности (таблицы), которая используется в модуле, перечислив атрибуты, с указанием: типа данных, заголовка, ограничений, имени в БД, ссылок на другие атрибуты и т.п.

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

Похожий раздел есть в ГОСТ-34.602-89 и называется он «Описание организации информационной базы».

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

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

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

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

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

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

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

Похожий раздел есть в ГОСТ-34.602-89 и называется он «Описание алгоритма».

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

Еще один немаловажный раздел, который должен быть упомянут в документе для подобного рода систем, посвящен правам доступа. В нем идентифицируются Роли, приводится их описание, а дальше указываются права доступа этих ролей к объектам данных и элементам интерфейса пользователя, описанным в спецификациях.

Следующим шагом, для удобства восприятия можно составить матрицы, в ячейках которых будут зафиксированы разрешенные действия для ролей, перечисленных в качестве столбцов, к имеющимся: процедурам, таблицам БД, элементам интерфейса пользователя и т.п., указанным в виде строк. А разрешительные действия можно обозначать, например, в виде первых букв английских слов (C- Create, R-Read, W-Write и т.д.).

Похожий подраздел есть, например, в ГОСТ-34.602-89 и называется он «требования к защите информации от несанкционированного доступа».

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

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

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

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

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

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

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

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