WEBURSITET.RU

Онлайн-курсы профессиональной разработки ПО

Блог экспертов Вебурситета

Какие виды требований важнее остальных?

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

 

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

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

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

Атрибуты качества

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

 

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

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

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

Функциональная и нефункциональная стороны продукта

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

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

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

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

Виды требований к программному продукту

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

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

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

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

Самый первый вид требований: бизнес-требования. Что это такое, обобщённо? Описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы.

Уровни требований к программному продукту

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

Есть такое хорошее число: три. Я его почти всегда использую, когда нам нужно описать разные варианты какой-то проблемы или какого-то явления. Часто бывает полезно разбить его на 3 части, чтобы описать два крайних случая и то, что находится посередине. Этот подход очень активно используется при выделении уровней требований.

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

Что такое требования к программному продукту

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

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

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

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

Мне не нравится это определение тем, что оно требует ответов на многие вопросы.

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

Применение диаграмм VISIC при разработке бизнес-требований

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

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

Пример использования VISIC при анализе и разработке требований (видео)

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

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

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

Диграммы в жизни аналитика — фрагмент вебинара

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

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

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

Описание и ссылка на полную запись вебинара здесь: Диаграммы в жизни аналитика.

Сообщение об использовании cookie – VISIC на практике

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

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

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

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

Плагин Requirements Yogi для Confluence: обзор и запись вебинара

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

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

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

Требования к системе управления требованиями

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

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

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

ГОСТ 34 и классификация требований – запись вебинара

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

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

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

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

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

 

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

Почему сайт — это не автоматизированная система

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

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

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

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

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

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

Терминологические ловушки ГОСТ 34

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

 

Тернист и сложен путь аналитика, впервые выбравшего ГОСТ 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 в проектах заказной разработки по ГОСТ.

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

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

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

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

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

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

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

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

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

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

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

Партнёры и друзья



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