6 апреля я провёл бесплатный вебинар Разработка требований в Confluence с использованием плагина Requirements Yogi. В этой статье я привожу краткий обзор того, о чём рассказывалось на вебинаре. Это поможет вам решить, стоит ли потратить примерно полтора часа своего времени на просмотр записи.

Atlassian Confluence – широко распространённая wiki-система, используемая в компаниях для ведения корпоративных баз знаний и разработки документации. Во многих компаниях Confluence также используют для документирования требований к ПО. Система «из коробки» не предоставляет каких-либо специальных возможностей для разработки и управления требованиями. Но открытая архитектура позволяет добавлять такие возможности с помощью устанавливаемых расширений (плагинов).

Одним из таких расширений является плагин Requirements Yogi.

На просторах интернета периодически появляются статьи, сравнивающие возможности программных инструментов для управления требованиями по разным критериям. Я одно время коллекционировал ссылки на эти статьи, но довольно скоро выяснилось, что они очень быстро утрачивают свежесть. Одни продукты уходят с рынка, другие появляются. «Протухают» сами ссылки, переставая куда-либо ссылаться. Но самое главное: стремительно изменяются представления о том, как должна выглядеть и что должна уметь система управления требованиями (СУТ), и поэтому устаревают критерии оценки, которые когда-то казались актуальными авторам этих статей.

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

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

В этом вебинаре рассматривается структура Технического задания, соответствующего ГОСТ 34, в сравнении с классификацией требований по Вигерсу. ТЗ по ГОСТ сопоставляется с документами требований, которые предлагают другие методологии разработки ПО: Vision, документы пользовательских требований, SRS.

Вебинар будет полезен для тех аналитиков, которые изучали методы разработки требований «по Вигерсу», но которым приходится работать с техническими заданиями «по ГОСТу».

Виды требований в ТЗ по ГОСТ 34 from Grigoriy Pechenkin.

В вебинаре используется майндмэп, описывающий структуру ТЗ по ГОСТ 34, который можно скачать по этой ссылке:
Структура ТЗ по ГОСТ.xmind

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

Вебинар проводился в рамках курса «Эффективная разработка требований».

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

Вопрос был задан как комментарий к моему заявлению:

— Мне категорически не нравится идея подводить однопользовательские приложения в веб под определение АС.

— А почему? Чем чревато?

Краткий ответ такой: чревато тем, что вместо сайта у вас получится АС, а пользователей к этому жизнь не готовила. :)

Более подробный ответ ниже.

ГОСТ - это законодательно утвержденный феншуй!
(Народное творчество)

Тернист и сложен путь аналитика, впервые выбравшего ГОСТ 34 для описания требований к системе. Опасности подстерегают его на каждом шагу.

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

Ловушка первая. Пользователь.

Вот, например, смотрит аналитик на описание жизненного цикла процесса создания системы, и видит в нём первый этап:
1 Формирование требований к АС
1.1 Обследование объекта и обоснование необходимости создания АС
1.2 Формирование требований пользователя к АС

При виде этого текста аналитик радуется: такие знакомые слова — требования, пользователь. И делает вывод:

«На базе полученных данных необходимо выявить основные функциональные и пользовательские требования к АС.» (Цитата отсюда http://www.it-gost.ru/content/view/93/51/).

Всё прямо по Вигерсу — вот же они, эти требования, на картинке!

Ан нет. Здесь его подстерегает первая ловушка.

При обсуждении статьи о самых главных диаграммах в фейсбуке мне задали вопрос: «Зачем вообще описывать деятельность в виде диаграммы? Или более общим образом — зачем нужно моделировать? А то это как-то выпало из статьи, как типа очевидное (а на самом деле нет)».

Вопрос о том, зачем вообще нужно моделировать, мы пока оставим открытым. Очень уж он всеобъемлющ. По большому счёту, всю нашу разумную (и не только разумную) деятельность можно свести к моделированию.

А вопрос о диаграммах я позволю себе переформулировать так, как я его понял: зачем нужно визуальное моделирование при разработке ПО?

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

Все они вам хорошо знакомы, хотя часто маскируются под разными названиями.

Это:

• диаграмма последовательности действий;

• диаграмма смены состояний;

• диаграмма взаимодействия объектов.

Почему они главные?

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

Во-вторых (которое проистекает из «во-первых»), они представляют набор, достаточный для моделирования любых процессов, причём на любом уровне детализации.

Давайте посмотрим на них поближе.

Запись вебинара «Версионирование требований», прошедшего 5 марта 2014 года в рамках серии дискуссионных вебинаров Сообщества аналитиков.

Ведущая: Ирина Сурова

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

Вебинар проходил в рамках курса «Эффективная разработка требований».

О классификации требований from Grigoriy Pechenkin on Vimeo.

Введение

Некоторое время назад мы с Алексеем Киселевым анонсировали старт работ по исследованию возможностей внедрения СУТ Devprom в проектах заказной разработки по ГОСТ.

Макет экрана работы с системой представлен ниже

Точное название системы — Devprom ALM, но нас интересовал этот продукт только с точки зрения управления требованиями, по крайней мере, на начальном этапе.

Мы не хотели, да и не могли кардинально менять существующие процессы разработки, основная суть которых заключалась в требованиях ГОСТ 19, 34 и 2.105.

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

СУТ должна была позволить:

— экспортировать/импортировать документы MS Word, содержащие форматирование стилями с использованием фильтров;

— работать с атрибутами требований;

— работать с запросами на изменение;

— работать с версиями требований;

— делать трассировки требований между собой и на задачи в Jira (в перспективе).

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

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

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

В процессе аналитической работы на наших проектах наблюдаются следующие проблемы:

• Требования с незначительной периодичностью теряются;
• В требованиях тяжело найти нужную версию;
• Влияние новых требований на проект оценивается аналитиком, опираясь исключительно на его опыт и незатуманенную память;
• Надо делать Excel-таблицы для выявления степени покрытия требований заказчика постановками;
• Так как людей запрещено приковывать к батареям и/или отбирать у них паспорта, а аналитики относятся к категории людей, то необходимо хранить полную историю изменений требований, их взаимосвязи (особенно, если речь идёт о связанных нескольких проектах) источники. А ещё их надо уметь быстро и правильно находить. Это трудоемкая задача, которую тяжеловато делать исключительно в вышеупомянутом Excel и Word: сразу хочется как-то автоматизировать поддержание актуальности ссылок, дабы не пребывать в глубочайшей депрессии в момент их актуализации.

Запись вебинара Требования не нужны аналитики (поставь запятую, где хочешь), проведенного 22 октября 2013 в рамках серии дискуссионных вебинаров Сообщества аналитиков.

Ведущий: Александр Байкин.

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

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

В своей книге «Agile Software Requirements» Дин Леффингуэл сделал заявление, которое сбивает с толку не только приверженцев «лёгких методологий», но и опытных аналитиков.

Заявление выглядит так:

User Stories Are Not Requirements

Пользовательские истории — это не требования

Конечно, кажется странным, зачем детально описывать что то, что не является требованиями, в книге с названием «Гибкие требования». Но давайте попробуем разобраться, что же автор на самом деле имел в виду.

У понятия «требование к ПО» много определений. Пожалуй, общепризнанным является определение IEEE:

Требование — это условие или возможность, необходимое пользователю для решения его задачи или достижения цели.

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