О работе с требованиями и документами

Наконец-то завершил написание статьи об опыте работы с требованиями и документами в системе управления проектами "Девпром" на примере одного проекта. Прочитать полностью статью вы сможете по ссылке ниже.

Atlassian Confluence в работе аналитика

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

• Confluence в жизни аналитика — Часть 1.
• Confluence в жизни аналитика — Часть 2.

Однако, возможности у системы действительно богатые.

Организация работы с требованиями и документацией в TFS

Пополняю свою коллекцию публикаций на тему организации работы с требованиями и проектной документацией интересной презентацией от Александра Шамрай.

Особенно выделю моменты с трассировками разделов документации на проектные артефакты.

Организация работы с требованиями и документацией в TFS from Александр Шамрай

Отзыв на книгу "Требования для программного обеспечения: рекомендации по сбору и документированию" (Илья Корнипаев)

Недавно коллеги привезли с конференции "Analyst Days 2013" новую книгу по требованиям от Ильи Корнипаева — "Требования для программного обеспечения: рекомендации по сбору и документированию". Несколько дней потребовалось, чтобы освоить материал.

Что сразу привлекло в книге — ее практическая направленность и довольно-таки сжатый объем (всего 118 страниц). Тем не менее, эти 118 страниц дают первоначальное представление о работе IT-аналитика в полной мере и могут начинающим специалистам в кратчайшие сроки определить имеющиеся и необходимые навыки, а также принять решение о целесообразности построения карьеры в области ИТ-анализа.

Что самое интересное, во введении сразу же приведены основные правила, которых стоит придерживаться во избежание ошибок:

1. Не нужно изобретать велосипед.
2. Не существует универсального шаблона, который бы помог решить любую задачу.
3. Старые проверенные средства работают, т.е. консерватизм — не всегда плохо.
4. В основе любого успешного проекта, в первую очередь, лежит взаимопонимание.
5. Работа аналитика в первую очередь — это работа с людьми, а уже потом — это инженерная работа.
6. Аналитик — это доктор.
7. Чтобы добиться успеха, необходимо прилагать усилия.

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

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

• Способ прототипирования в Excel с использованием VBA. Ранее я слышал о таком применении Excel, но не видел, и, тем более, не применял на практике (только прототипы в MS Visio). Теперь хочу изучить VBA и попробовать данный способ на одном из проектов.
• Способ выбора представителя со стороны заинтересованных лиц. Это должен быть человек, обладающий и знаниями, и умениями, т.е. тот человек, которому руководство доверяет обучение новичков.
• Главный вопрос аналитика — "Зачем?" (для связи требований от ЗЛ с их целями).

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

Считаю, что для входа в профессию ИТ-аналитика и принятия решения о целесообразности построения карьеры в области ИТ-анализа данная книга — то, что нужно. После неё можно читать уже и более объемную книгу "Путь аналитика" (Перерва, Иванова), а потом — все основные зарубежные аналитические книги (Карл Вигерс, Алистер Коберн, Дин Леффигуэлл и т.п.).

Трассировка: от определения проблемы к требованию

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

Одна из выявленных закономерностей (от проблемы к требованию) была визуализирована (см. диаграмму ниже). 

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

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

Материал для начинающих бизнес/системных аналитиков

Наталья Свешникова, системный аналитик из компании "Лаборатория Касперского" поделилась целой серией лекций об аналитике, оформленных в виде презентаций. Целевая аудитория — специалисты, начинающие свой путь в ИТ-анализе.

Лекции доступны в блогах сообщества системных аналитиков по ссылке.

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

Немного о контекстных диаграммах...

В последнее время довольно-таки активно читаю статьи с англоязычного ресурса http://www.modernanalyst.com.

Некоторые новшества и хитрости создания контекстных диаграмм были обнаружены в статье "Putting Systems Analysis “Into Context” using the Context Diagram".

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

Перевод статьи "Use Cases and Business Rules: Can They Work Together?"

Над переводом статьи "Use Cases and Business Rules: Can They Work Together?" я трудился еще года два назад, когда готовил материал для аналитического интернет-журнала "Analyze IT". Но четвертому выпуску так и не суждено было выйти, а держать полезный материал у себя в закромах — явно не мой принцип.

Поэтому приглашаю Вас к прочтению статьи "Варианты использования и бизнес-правила: могут ли они работать совместно друг с другом?". Кстати, данный перевод был использован Александром Байкиным в докладе "Бизнес-правила и дополнительные требования в вариантах использования (use cases)" на конференции ReqLabs 2012.

Практика: Разбиение требований в agile-проектах

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

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

Процесс создания ИТ-аналитиком проектных артефактов

Для себя делаю несколько выводов об общем процессе создания проектных артефактов ИТ-аналитиком.

Итак, процесс ИТ-аналитика по созданию артефактов (по сути, документации и моделей) можно представить в следующем виде:

1. Выявление целей и задач будущей автоматизированной Системы.
2. Описание бизнес-процессов объекта автоматизации в состоянии "как есть" (AS IS) - бизнес варианты использования.
3. Моделирование и описание концепции будущей Системы.
4. Описание системных вариантов использования. По сути, это первоначальные процессы, но в состоянии "как должно быть" (TO BE).
5. Формирование спецификации (SRS), или, другими словами, ТЗ, которое подробно описывает все функции будущей системы.
6. По результатам разработки - создание справочной системы, руководств и инструкций.

Всё наглядно иллюстрирую с помощью VAD-диаграмм (см. рисунок ниже). 

Коллеги, будут какие-либо дополнения/уточнения? Мне важно Ваше мнение.

Полезное ТЗ по ГОСТ серии 34

До недавнего момента о том, что такое ГОСТ серии 34 я только слышал. Хотя нет, пару раз ради интереса всё-таки читал ГОСТ 34.602-89 под названием "Техническое задание на создание автоматизированной системы" и даже пытался его как-то адаптировать под некий универсальный шаблон ТЗ, который я мог бы использовать постоянно, не придумывая каждый раз чего-то нового, а лишь исключая ненужные разделы из него. Но "адаптации" успехом так и не увенчались.

Каждый раз мною писались техзадания, структура которых была далека от того, что предлагает вышеуказанный ГОСТ. Да и заказчик, как говорится, не был требователен к тому, чтобы все было оформлено в соответствии со стандартом, и проекты были  небольшие: такие, что ГОСТ применять в них было нецелесообразно. И вообще я работал по сути техническим писателем ;)

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

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

• Статья С.А. Нужненко "Разработка полезного ТЗ по ГОСТ 34.602", содержащая множество практических сведений, а также ссылки на тематические статьи.
• Конечно же, сам стандарт на полезном сайте rugost.com с примерами заполнения некоторых разделов.

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

Да, кстати, была мысль разработать очередное ТЗ способом, суть которого я изложил в этой теме на форуме uml2.ru. Тема вызвала дискуссию.

Как говорится, я пока в поисках... в поисках оптимального варианта изложения требований. Надеюсь, когда-нибудь я его найду. Или он меня найдёт :)

НФТ или нефункциональные требования к ПО

Как-то в течение рабочей недели, читая блог Алексея Киселёва, обнаружил очень интересную ссылку на статью Натальи Желновой с названием "Нефункциональные требования к ПО: как их определять и откуда брать цифры".
Прочтение данного материала существенно расширило мои знания по поводу одного из видов требований к программному обеспечению, тем более, новые знания сразу же были применены в работе.

С удовольствием привожу ссылку на данную статью: http://softwarepeople.ru/blog/2011/07/11/non-functional-requirements01/.

Как создавать хорошие варианты использования? Советы

Не могу не отметить четкий и подробный перевод статьи-инструкции по написанию вариантов использования от Александра Шамрай. В совокупности с книгой Алистера Коберна данная инструкция «расставляет всё на свои места».

Из всей статьи можно выделить перечень важных моментов:

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

• Сценарий использования – это история о том, как бизнес (или система) и пользователи взаимодействуют.

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

• Сценарии использования преобразуют выражения «должен» на группы, которые обеспечивают наблюдаемое значение и контекст, организованные с точки зрения пользователя.

• Сценарии использования описывают и функциональность, и результаты.

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

Рекомендации по составлению вариантов использования:

• Распространенной ошибкой является путать требования со спецификациями проектирования.

• Диаграммы обеспечивают визуальный вспомогательный материал для сценария использования.

• Сценарии использования должны иметь один основной поток и несколько альтернативных потоков.

• Альтернативные потоки объясняют отклонение от основного потока.

• Ссылки определяют начало и конец альтернативного потока.

• Ссылки позволяют пользователям восстановить всю историю.

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

• Создание стиля для сценария использования позволяет писать и читать их быстрее и проще.

• Удобочитаемость может пострадать, если присутствует оператор «если» в потоке, потому что это обычно означает множественные требования.

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

• Плохо написанный сценарий использования имеет слишком много действий создания, чтения, обновления и удаления (СЧОУ), уменьшая ясность. Удаление деятельностей СЧОУ упрощает документ.

• Упорядочивание событий в потоке не всегда необходимо для достижения ясности.

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

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

Классификация требований к программному обеспечению и её представление в стандартах и методологиях

Недавно мне случайно попалась на глаза очень полезная презентация от Юрия Булуя на тему "Классификация требований к программному обеспечению и её представление в стандартах и методологиях".

В ней автор провёл отличное сравнение вариантов классификации требований к программному обеспечению в различных стандартах и методологиях, среди которых:

1. SWEBOK;
2. ГОСТ 34;
3. IEEE 830;
4. RUP;
5. Классификация К. Вигерса.

Сама презентация доступна для просмотра тут: http://cee-secr.org/2006/upload/files/63.pdf

Рекомендую для ознакомления!

Где купить «бумажного» Коберна?

Так как электронные варианты книг не очень люблю, потому что не люблю читать с экрана монитора – глаза быстро устают, да и электронной «читалкой» на данный момент ещё не обзавёлся, задался целью купить переведённый оригинал книги Алистера Коберна «Современные методы описания функциональных требований к системам». Что уж тут говорить, а книга действительно нужная для каждого it-аналитика.

Но столкнулся с проблемой – где её купить-то? По советам форумчан с uml2.ru отправил запрос на findbook.ru: книга была в наличии аж в 3-х книжных интернет-магазинах: books.ru, colibri.ru и в Чаконе.

Сперва заказал книгу в самарской Чаконе (дело было в ноябре прошлого года), при этом заполнил специальный бланк заказа, плюс ещё и на интернет-сайте Чаконы оставил заявку на приобретение. Сказали, что в срок от 2 недель до 3 месяцев оповестят меня. До сих пор никакой обратной связи нет…

Затем обнаружил, что на books.ru находится данная книга со статусом «есть в наличии». Обрадовался. Сразу же сделал заказ и оплатил его. Но вдруг, спустя некоторое время узнал, что «товар в настоящий момент снят с продажи и не может быть отправлен». Огорчился. Ладно хоть деньги вернули в полном объёме! Видно, что магазин дорожит своей репутацией и покупателями. Связь держали со мной постоянно, оповещали о состоянии запроса к поставщику. Ну да ладно, не получилось тут, думал, что получится в другом месте.

Третьей попыткой был заказ книги в интернет-магазине colibri.ru. Статус книги был аналогичный – «в наличии». Снова обрадовался. Оплатил заказ и доставку. Обещали после новогодних праздников прислать. Но не тут-то было: спустя несколько недель узнал то же самое – «книги нет в наличии» с соответствующей припиской:

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

Расстроился. Деньги до сих пор не вернули и на письма отвечают оооочень медленно.

В общем, интернет-магазинами я остался не доволен… А книгу-то хочется приобрести...

Use Case и функция системы - в чём отличия?

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

Как же отличить варианты использования (use cases) от функций системы? Как избежать их дублирования?

Ответ на этот вопрос и видение сложившейся ситуации опубликовал в своём блоге Юрий Булуй.

В сообществе UML2 также идёт активное обсуждение данного вопроса: http://www.uml2.ru/forum/index.php?topic=2978.0.

Главное, что я усвоил из вышеуказанного материала:

• Use Case и функция системы - далеко не одно и то же.
• Если я представлю себя пользователем будущей системы, то Use Cases - это описание тех задач/целей, которые я смогу решить с помощью системы.
• Функции системы - это "взгляд" изнутри системы на её окружение. Представляем себя находящимся внутри системы и определяем, что мы сможем сделать для внешнего мира  - пользователей, других систем и т.д.
• Одно из отличий функции от Use Case в том, что функция может быть декомпозирована, Use Case не может быть декомпозирован.

Бесплатное средство для моделирования бизнес-процессов

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

Для решения задач моделирования хочу предложить Вам абсолютно бесплатное и сравнительно новое средство для управления бизнес-процессами от мирового лидера в данной отрасли - компании IDS Scheer. Имя этому средству - ARIS Express.

Из информации на официальном сайте:

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

Следовательно, сразу же после того, как я узнал о существовании данного средства моделирования, мною были даны рекомендации на использование этого продукта в университете СГАУ им. Королёва, выпускником которого я являюсь. Дело в том, что во время обучения на 5 курсе нами, как студентами, была освоена демоверсия ARIS Toolset. Для работы с программой использовались USB-ключи. Это было очень  не удобно, тем более, что демоверсия заметно ограничивала возможности построения диаграмм. 

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

Основные возможности ARIS Express перечислены ниже: 

• Моделирование бизнес-процессов, организационных диаграмм, ИТ-инфраструктураы ландшафтов систем, моделей данных и др.;
• Быстрое моделирование с помощью подсказок (hotspots) для контекстно-чувствительного размещения объектов;
• Сбор информации с помощью специальных таблиц и автоматическое создание моделей с помощью функциональности smart design;
• Возможность определить свои фрагменты для часто используемых комбинаций объектов;
• Полезные справки в дополнение к проверенной методологии ARIS;
• Возможность обмениваться и обсуждать свои модели и идеи на сообществе ARIS Community;
• Все результаты можно перенести и использовать в профессиональных BPM-инструментах платформы ARIS.

Сравнение ARIS Express с профессиональными продуктами ARIS:
http://www.ariscommunity.com/users/nikolay-eshich/2009-09-10-aris-express 

Скачать ARIS Express: http://www.ariscommunity.com/aris-express/download

Видеоуроки ARIS Express: http://www.ariscommunity.com/aris-express/tutorials

5 уровней зрелости требований к программному обеспечению

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

Для себя сделал вывод, что сейчас нахожусь на начальном этапе уровня № 2: в техзаданиях, которые составляю, начал вести сквозную нумерацию требований. Может быть, на данный момент такая методика оправданна, т.к. проекты, в которых принимаю участие, не настолько масштабны и требуют лишь наличия задокументированных требований.

Но, однозначно, есть к чему стремиться!

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

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

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

После первоначального ознакомления с документацией:

1. Смотрим оглавление справки, "видим" компоненты системы. Таким образом, получаем высокоуровневое представление о системе - функциональные области системы.
2. Руководство пользователя - это всегда какая-либо последовательность действий пользователя для достижения определённой цели. Значит, есть уже почти готовые варианты использования. Остаётся только доработать их!
3. Что касается пользовательского интерфейса, то, как правило, справочные документы пользователя уже имеют готовые скриншоты экранных форм. Дело за малым - остаётся спроектировать интерфейс, опираясь на аналоги.
4. В итоге, необходимо актуализировать требования к разрабатываемому продукту, добавив либо новые, либо изменив существующие требования в соответствии с необходимой функциональностью.

Оригинал статьи: http://grigorash.ru/archives/85

Методы инженерии требований к программному обеспечению

В первую очередь, хочу поделиться полезным и очень важным материалом для бизнес-аналитика (особенно начинающего) - презентацией Юрия Булуя на тему "Техники и приёмы, используемые в инженерии требований.