О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 2

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

    Список литературы
    [1] К. И. Вигерс, Разработка требований к программному обеспечению, Издательско-торговый дом «Русская Редакция», 2004, p. 576.
    [2] А. Коберн, «Современные методы описания функциональных требований», Лори, 2002, p. 288.
    [3] У. Д. Леффингуэлл Дин, Принципы работы с требованиями к ПО, Вильямс, 2002, p. 448.
    [4] ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
    [5] Б. Г. Р. Д. Якобсон А., Унифицированный процесс разработки программного обеспечения, Питер, 2002, p. 496.
    • +13
    • 7,5k
    • 6
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 6
    • 0
      В XP ТЗ не делают.
      • +2
        … в приведенном выше примере таблицы ролей, нет описания целей заинтересованных лиц и т.п. Эти подробности важны для аналитика на этапе формирования требований, но практически бесполезны для разработчиков.

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

        Вообще, в этой части подробно описано, как аналитик ворует работу у программистов и архитекторов, принимая за них все решения. А потом аналитики собирают митапы, чтобы обсудить вопрос "Почему программисты не читают требования".
        • +1
          Отличная статья, все разложено по полочкам, чувствуется вдумчивость и многолетний опыт. Спасибо автору! Рассмотренный пример наглядный и релевантный.
          На мой взгляд, требует комментариев применяемая классификация требований FR1.3.1, поскольку из названия типа требования (например, рамки качества) не совсем понятно, что имеется в виду.
          Ещё интересно, как используется система тегов идентификаторов для управления требованиями. Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?
          • 0
            интересно, как используется система тегов идентификаторов для управления требованиями.

            Об этом упомянуто в 3 части.
            Применяются ли функции отслеживания изменений, фильтров, трассировки требований и т.п.?

            Это уже инструмент, конечно он должен быть в каждом конкретном технологическом процессе. Я же в данной статье обращаю главное внимание на форму составления спецификаций.
          • 0
            Статьи (3 части) хорошо разобраны и вполне применимы, имхо. Имеют полное право быть! Но неужели «отображению на визуальных формах» описывается без прототипов форм?

            2) Да и в целом, посыл прост (он есть у вас в первой части) — договоритесь со своими разработчиками о форме требований, удобных для них. В разных проектах для разных разработчиков — все по-разному.
            • 0
              Но неужели «отображению на визуальных формах» описывается без прототипов форм?

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

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

            Самое читаемое
            Интересные публикации