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

Когда-то очень давно, в прошлой жизни я руководил ИТ-бизнесом.
Поставил коллегам задачу сделать методику и технологию управления требованиями. И мы это сделали. Важным элементом методики был курс обучения по управлению требованиями, подготовленный по книге Вигерса. Именно тогда я узнал об этой книге и захотелось ее прочитать, но не было возможности, по другому расставлял приоритеты.

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

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

Хочу проверить свою силу воли и дисциплину. Для меня важно довести до конца задачу — прочитать книгу, даже если она окажется сложной или требует времени. Это поможет мне убедиться, что я могу осилить такой объём информации и применить его на практике.

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

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

Я хочу прочитать эту книгу для того, чтобы:

1. Научиться выбирать представителей клиента для сбора требований.
2. Закрепить понятия: пользовательские требования, бизнес-правила, функциональные требования, требования к данным и нефункциональные требования.
3. Узнать способы формулирования требований, научиться формулировать требования.
4. Узнать способы управления требованиями, технологии для реагирования на изменение требований по ходу проекта.
5. Уложить всю эту теорию по «полочкам» в своей голове с помощью практических заданий.

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

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

Часто бывают ситуации, что требования в течение проекта изменяются, и как поступать? Где фиксировать изменения, как взаимодействовать с клиентом при этом, как отслеживать эти изменения, чтобы при этом границы проекта остались прежними?

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

Зачастую на проекте ощущаешь себя как на уроке литературы в школе: при прочтении некоторого набора тезисов прям слышу голос своего учителя по литературе - "что хотел сказать автор данным произведением?"

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

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

Книгу "Разработка требований к программному обеспечению" Карла Вигерса и Джоя Битти часто любят сравнивать с библией аналитика. Талмуд, катехизис, настольная книга, must have, обязательно к прочтению. Если подобные отзывы о книге получаешь хотя бы от пяти персон, уже интересно. А если видишь отсылку к ней на курсах и выступлениях, становиться понятно, что это литература, достойная внимания.
Исторически сложилось, что роль "1С-аналитик" выделилась относительно недавно. До сих пор идут споры, ближе он к бизнес-аналитику или всё же это разновидность системного аналитика (на обе последние должности, в отличии от 1С-ной версии, уже разработаны профессиональные стандарты). Типично, что аналитик 1С вырос из консультанта 1С, "от розницы и сопровождения", и потому системному подходу к разработке программного обеспечения приходится и учиться, и учить.
Разработка требований к ПО, представленная в данной книге, представляет собой универсальные практические приёмы, не зависящие от фреймворка и языка программирования, при этом применимые как для проектной, так и для продуктовой разработки. А это является подходящим вариантом для привнесения в проекты на 1С "взрослого" подхода к разработке программных продуктов - повышение качества при реализации продукта и уровня систематизации при управлении проектом.
Но как бы не боролись за единый подход, специфика области и нюансы платформы игнорировать не получится, а значит приёмы из книги необходимо адаптировать для получения "жизнеспособной мутации".
В свете вышеизложенного для меня чтение и обсуждение данной книги имеет целью углубить навыки системного анализа, обменяться опытом с коллегами и, в перспективе, применить с пользой на своих проектах.

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

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

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