Фрагмент моего выступления на конференции Analyst Days #19 Пять граней мышления аналитика.

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

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

Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.

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

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

Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.

Практика, о которой пойдёт речь в этом уроке, — выявление видов пользователей. Вообще, в книгах они называются обычно ролями пользователей. Но я решил здесь всё-таки использовать в названии урока другое слово, чтобы отделить понятие, используемое при разработке 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).

Текстовая расшифровка седьмого урока курса Введение в профессию аналитика.

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

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

Текстовая расшифровка шестого урока курса Введение в профессию аналитика.

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

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

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

Текстовая расшифровка пятого урока курса Введение в профессию аналитика.

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

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

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

Текстовая расшифровка четвёртого видеоурока курса Введение в профессию аналитика.

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

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

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

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

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

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

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

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

Текстовая расшифровка второго видеоурока курса Введение в профессию аналитика.

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

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

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

Текстовая расшифровка первого видеоурока курса Введение в профессию аналитика.

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

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

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

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

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

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

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

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

В этом коротком ролике показаны типичные шаги, выполняемые при разработке бизнес-требований, и диаграммы языка VISIC, которые можно при этом использовать.

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

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

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

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

В этом ролике на примере простой задачи автоматизации показано использования диаграмм VISIC при анализе и разработке требований.

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

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