Паттерны требований к ПО – про что эта книга?

В 2007 году в издательстве Майкрософт пресс вышла книга Software Requirement Patterns (Паттерны требований к ПО) от автора Stephen Withall (Стивена Витхолла). Несмотря на то, что с даты выхода книги прошло уже более 10 лет, идеи и подходы, в ней изложенные, продолжают оставаться актуальными.

Рассказать о книге лучше, чем это сделал небезызвестный Карл Вигерс, который написал к ней предисловие, я вряд ли смогу. Поэтому, вот отрывок из предисловия, который вводит в тему книги:

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

  • С чего начать?
  • Откуда мне знать, когда я закончу?
  • Насколько подробными должны быть мои требования?
  • Пропустил ли я какие-либо требования?
  • Я не упустил из виду важную информацию в требованиях, которые я написал?

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

Паттерны требований к ПО могут помочь любому аналитику лучше писать требования. Эти паттерны обеспечивают способ воплощения всеобъемлющих и структурированных знаний о различных типах требований. Разработка требований – это путь исследования, а не просто процесс сбора или транскрипции. Паттерны, представленные Стивом, могут помочь аналитикам задать правильные вопросы, чтобы правильно понять и определить требования многих типов на соответствующем уровне детализации. С точки зрения “знай свою аудиторию”, паттерны включают в себя руководство, чтобы помочь разработчикам и тестировщикам, которые должны принять требования к следующим этапам разработки. Люди учатся на примерах, и они работают более эффективно с помощью паттернов, а не с пустой страницы.

Так что же такое «Паттерн требования к ПО»?

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

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

Т.е. паттерн требования – это не только, определённым образом форматированный шаблон будущего требования в Word или Excel, но ещё и рекомендации по тому КАК его писать, КАК использовать и тестировать.

Автор рекомендует следующую структуру паттерна требований:

  • Основные сведения (версия, автор, язык, предметная область, связанные паттерны, класс требования и т.п.)
  • Применимость
  • Обсуждение
  • Содержание
  • Шаблон
  • Примеры
  • Дополнительные требования
  • Рекомендации по разработке
  • Рекомендации по тестированию

 

Паттерн требования «Утверждение» (Approval)

В книге содержатся уже готовые паттерны требований (всего их 37), которые можно адаптировать и использовать в проектах. Чтобы читателю было понятнее, я сразу приведу немного сокращённый пример одного паттерна из книги. Он будет касаться подтверждения (Approval) какого-то действия.

Основные сведения

Связанные паттерны: нет

Ожидаемое количество требований (по этому паттерну): от 0 до 6

Класс: Функциональный

Применимость

Используйте паттерн требования «Утверждение», чтобы указать, что конкретное действие (или набор действий) должно быть утверждено (или утверждено только в некоторых случаях) вторым лицом до его выполнения.

Обсуждение

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

Представьте себе Банк, в котором кассир должен иметь подтверждение от руководителя для любого крупного снятия наличных. Это звучит достаточно просто. Но что значит крупная сумма? Зависит ли это от кассира к кассиру: некоторым кассирам более доверяют, чем другим? А что значит – руководитель? Может ли любой руководитель одобрить это действие, или только непосредственный начальник кассира? Что делать, если обычный утверждающий отсутствует? Что делать, если кто-то еще хочет выполнить действие, которое влияет на ожидающее действие (например, если мы ждем утверждения для дебетования банковского счета, а приходит другое дебетование на тот же счет). Каждая деталь должна быть выяснена и указана в паттерне требований.

Содержание

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

  1. Какие действия необходимо подтверждать?
  2. При каких условиях необходимо подтверждение?
  3. Кто и при каких условиях может подтверждать действия?
  4. Как быстро требуется утверждение?
  5. Как происходит утверждение?
  6. Что происходит, если подтверждение не получено?

Шаблон

Паттерны требований. Паттерн требования "Подтверждение"

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

Пример

Паттерны требований. Пример паттерна требования "Подтверждение"

Дополнительные требования

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

Паттерны требований. Пример дополнительного требований

Рекомендации по разработке

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

Рекомендации по тестированию

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

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

Мои впечатления

Конечно, в чистом виде, просто взять паттерны требований из книжки и начать их использовать нельзя. Их необходимо адаптировать, с учётом корпоративной культуры в целом и подхода к бизнес-анализу, в частности. Про подход к бизнес анализу можно посмотреть в отдельной статье: Подход к бизнес-анализу (BABOK 3.0)

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

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

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

Где купить книгу

Книгу ещё можно найти в продаже на Амазоне. Стоимость её составляет 39,99$ (есть подержанные экземпляры за 12,48$). Доставка в РФ есть. Книга на английском языке. Перевода на русский я не видел.

 

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