Первая важная грань мышления аналитика — системное мышление.

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

На ближайших трёх вебинарах мы познакомимся с тремя наиболее популярными методами разработки пользовательских требований. Я надеюсь, вы понимаете, что за один вебинар изучить ни один из этих методов невозможно, потому что нужно много практики. Я свою задачу вижу в том, чтобы только познакомить вас с этими методами — в надежде, что если вы будете их использовать, то вы где-то более углубленно их изучите. Либо изучите по книгам, либо пройдёте курсы. По каждому из этих методов есть множество курсов. Моя задача — дать вам обзор этих методов, чтобы вы понимали, в чём их суть, и в каких условиях их лучше всего применять.

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

Практика, о которой пойдёт речь в этом уроке, — выявление видов пользователей. Вообще, в книгах они называются обычно ролями пользователей. Но я решил здесь всё-таки использовать в названии урока другое слово, чтобы отделить понятие, используемое при разработке User Stories, от других ролевых моделей. Мы сейчас поймём, что имеется в виду.

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

Рассмотрим следующий раздел Концепции, который называется «Другие требования к продукту». Обычно в этот раздел выносят требования, касающиеся нефункциональной стороны, например:

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

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

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

Мы с вами познакомились с несколькими методами разработки пользовательских требований. На самом деле, методов было два: это Use cases (юзкейсы) и User stories. И плюс дополнительный метод — наверное, не столько разработки, сколько выявления пользовательских требований: персонажи. По-английски он называется Personas, а на русский язык его обычно переводят как «персоны» или «персонажи».

У нас была сравнительная табличка, когда мы сравнивали ролевые модели методов Use cases и User stories. Я здесь добавил ещё одну табличку. Иногда возникает вопрос: какой метод лучше применим в нашем проекте, каким из них воспользоваться? Для того, чтобы эту оценку правильно сделать, нужно сравнить их достоинства и недостатки. Мы о них говорили достаточно много в процессе курса, начиная с самых первых вебинаров, и более детально, когда мы изучали эти методы. Здесь, на этой табличке, подведен итог.

Давайте теперь поговорим о критериях качества требований. Требования мы разрабатываем, но насколько они являются хорошими или плохими? По этим критериям определяется качество работы аналитиков.

Существует несколько подходов или моделей определения качества требований. Они в основном отражаются в виде таких списков. Я несколько таких списков сейчас вам приведу, а потом мы их сравним между собой и поймём, чем они отличаются, и в каких ситуациях они применимы.

Этот список я взял из статьи бывшего директора по маркетингу IBM (ссылка на статью здесь приведена).

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

На уровне бизнес-требований сводными документами, как мы говорили, является концепция (Vision) и техническое задание.

Я вам сначала покажу примеры концепций, а потом мы сформулируем выводы. Rational Unified Process, о котором я говорил, — это фактически большая база знаний о том, как создавать разные продукты. Мы ему должны быть благодарны, во-первых, за явное выделение роли аналитиков и их специализаций. Именно в RUP были детально впервые описаны разные роли аналитиков — в частности, бизнес-аналитика, системного аналитика и ещё некоторые дополнительные роли.

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

Вот две крайности, которые давно уже у всех на слуху. Слева у нас картинка из статьи Уинстона Ройса о водопадном процессе, которая была издана в материалах НАТО ещё в 1968 году. Это, собственно, иллюстрация водопада. А справа картинка, может быть, менее известная, это крайний способ Agile разработки — экстремальное программирование.

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

Давно существует такое разделение. Я не назову сейчас первоисточник. Но есть, например, такая модель зрелости управления CMMI, которая описывает группы процессов, которые должны быть реализованы в компании. В данном случае речь идет о компаниях — разработчиках программного обеспечения. Модель CMMI делит эти компании на несколько уровней зрелости. Т. е. начальный уровень находится внизу — первый, практически хаотичный. Чем больше процессов у вас реализовано и отработано, тем выше уровень, на котором вы находитесь. Активно довольно применяется эта модель. Есть специальные люди, которые проводят сертификацию компаний в соответствии с этой моделью, хотя в России их не очень много. Если компания сертифицировалась по CMMI до какого-то уровня, например четвертого, то она обычно этим гордится, потому что это может быть существенно при работе с западными заказчиками, которые на эту сертификацию смотрят.

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

Что, собственно, стоит за этими группами процессов? Какие процессы в них входят?

Когда мы разрабатываем требования, обычно мы их сводим в какие-то совокупности. Сейчас, правда, эти совокупности более размыты из-за применения систем управления требованиями, где они просто фиксируются в базе данных, из-за чего иногда размывается деление по уровням и видам требований. Но, тем не менее, все аналитики сталкиваются со сводными документами требований. Давайте рассмотрим основные понятия, относящиеся к этим документам.

Если вы помните, на картинке с классификацией требований, которую я взял из книги Вигерса, на каждом уровне присутствовали названия документов, в которые эти требования должны собираться. На уровне бизнес-требований это был документ об образе и границах проекта (Vision), на пользовательском уровне — спецификация пользовательских требований (в предыдущих редакциях книги там была спецификация вариантов использования, так как в то время этот метод описания требований был широко распространён), и самом на нижнем уровне — так называемая спецификация требований к программному обеспечению (Software Requirements Specification или SRS).

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

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

Так какие же требования важнее остальных?

Мы рассмотрели разные виды требований и рассмотрели разные виды качества.

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

Давайте поговорим о атрибутах качества, чтобы мы понимали, что стоит за этим термином.

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

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

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

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

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

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

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

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

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

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

Давайте для начала разберёмся с делением требований по уровням.

На этой картинке представлена пирамидка из книги Леффингуэлла и Уидрига «Принципы работы с требованиями к программному обеспечению», которая уже упоминалась в предыдущей главе. Она описывает три уровня требований.

Прежде чем говорить о требованиях, нам нужно определиться, что мы под ними понимаем.

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

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

Первое, что приходит в голову, когда мы хотим найти определение чему-нибудь, — поискать в Википедии. Русскоязычная страница Википедии даёт нам такое определение:

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

Мне не нравится это определение тем, что оно ставит вопросов больше, чем даёт ответов.

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

В какой форме существуют эти утверждения? Если у меня в голове есть какие-то утверждения относительно атрибутов системы, но я их нигде не документировал, то являются ли они требованиями?

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

Все демонстрируемые диаграммы нарисованы с использованием бесплатного редактора yEd.

Файлы с диаграммами можно скачать по этой ссылке: примеры диаграмм на языке VISIC.

Все диаграммы разработаны в бесплатном редакторе yEd.

Использованные в ролике диаграммы, а также палитру VISIC для редактора yEd вы можете скачать одним архивом по этой ссылке: Примеры диаграмм.

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

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

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

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

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

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

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

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

Виды требований в ТЗ по ГОСТ 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 даже не собирались делать из него язык программирования. Его придумали для того, чтобы обычные люди могли работать с базами данных. (Да-да, даже гуманитарии.)

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

User Stories Are Not Requirements

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

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

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

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

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