Цитаты из книги К. Вигерса "Разработка требований к программному обеспечению"

Часть 1

• Многие исследования показывают, что на ошибки, внесенные на этапе сбора требований, приходится от 40 до 50% всех дефектов, обнаруженных в программном продукте (Davis, 2005). Некорректные сведения от пользователей и недостатки определения и управления требованиями клиентов — основные причины провалов проектов.
• Требования это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы. (Иен Соммервилл)
• Бизнес-требование - высокоуровневая бизнес-цель организации или заказчиков системы
  Бизнес-правило - политика, предписание, стандарт или правило, определяющее или ограничивающее некоторые стороны бизнес-процессов. По своей сути это не требование к ПО, но оно служит источником нескольких типов требований к ПО
  Ограничение - ограничение на выбор вариантов, доступных разработчику при проектировании и разработке продукта
  Внешнее требование к интерфейсу - описание взаимодействия между ПО и пользователем, другой программной системой или устройством
  Характеристика - одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
  Функциональное требование - описание требуемого поведения системы в определенных условиях
  Нефункциональное требование - описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система
  Атрибут качества - вид нефункционального требования, описывающего характеристику сервиса или производительности продукта
  Системное требование - требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
  Пользовательское требование - Задача, которую определенные классы пользователей должны иметь возможность выполнять в системе, или требуемый атрибут продукта
• Требования к ПО состоят из трех уровней — бизнес-требования, пользовательские и функциональные требования. Вдобавок в каждой системе есть свои нефункциональные требования.
• Связи между требованиями 
• Бизнес-требования (business requirements) описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему.
• Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта.  Пользовательские требования описывают, что пользователь должен иметь возможность делать с системой.  «Как пассажир я хочу зарегистрироваться на рейс, чтобы можно было сесть на самолет»
• Функциональные требования (functional requirements) определяют, каким должно быть поведение продукта в тех или иных условиях.  Описываются в форме традиционных утверждений со словами «должен» или «должна».  «Если в профиле пассажира не указаны предпочтения по выбору места, система резервирования должна сама назначить ему место»
• Системные требования (system requirements) описывают требования к продукту, который содержит многие компоненты или подсистемы (ISO/IEC/IEEE 2011)
• Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, отраслевые стандарты и вычислительные алгоритмы
• Атрибуты качества (quality attributes) еще называют параметрам качества, требованиями по уровню обслуживания и т.п. Они представляют собой описание различных измерений характеристик продукта, которые важны для пользователей или для разработчиков и тех, кто будет обслуживать систему, таких как производительность, доступность и переносимость.
• Ограничения (constraints) проектирования и реализации накладывают границы на возможности выбора разработчика при проектировании продукта
• Спецификация требований содержит требования к продукту и не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта, сведений о тестировании и тому подобной информации. Удалите указанные элементы из требований, чтобы из этого документа было абсолютно ясно, что надлежит построить команде разработчиков.
• «Самая сложная часть построения систем ПО — решить точно, что же создавать. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, механизмами и иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Никакая другая часть не дает более трудные для исправления ошибки»  Ф. Брукс
  
• Время, которое тратится на выяснение потребностей пользователей, представляет собой высокоэффективную инвестицию в успех проекта.
• Недостатки в требованиях представляют собой угрозу успеху проекта, где успех означает выпуск продукта, который удовлетворяет ожиданиям пользователей по качеству и функциональности при соблюдении бюджета и графика проекта.
• Под требованиями-«бантиками» (gold plating) понимают отсутствующие в спецификации требований функции, добавленные разработчиками, потому что им кажется, что это понравится пользователям.
• Без адекватного участия клиента в конце проекта неизбежно возникает разрыв ожиданий (expectation gap) — пробел между тем, что клиенту реально нужно, и тем, что предоставили разработчики, основываясь на том, что они знали в начале проекта
• Заинтересованное лицо (stakeholder) — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.
• Когда при работе над проектом нагнетается напряжение, очень легко забыть, что у всех участников единая цель — создать программный продукт, ценный для бизнеса и отвечающий чаяниям всех участников проекта. Аналитик обычно оказывается ключевым человеком, на плечи которого ложится налаживание этого сотрудничества.
• Требования должны быть написаны и организованы так, чтобы их было легко понимать.
• Выявление и спецификация требований — одни из самых трудных задач в разработке ПО.
• Очень ценно представлять отдельные требования несколькими способами, например в текстовой и графической форме или одновременно в виде требований и тестов. Это позволит выявить их особенности и проблемы, не заметные при представлении одним способом.
• Модели позволяют выявить некорректные, несогласованные, отсутствующие и избыточные требования. К таким моделям относятся диаграммы потоков данных, диаграммы «сущность-связь», диаграммы перехода состояний, таблицы состояний, карты диалоговых окон, деревья решений.
• Ведите список бизнес-правил отдельно от требований проекта, поскольку правила обычно существуют вне рамок конкретного проекта.
• Задача аналитика — собрать и проанализировать мнения заинтересованных сторон и лиц, отразить их в спецификации требований и передать информацию другим заинтересованным в проекте лицам. Аналитик помогает участникам проекта прояснить, действительно ли пожелания, которые они высказывают вслух, — это то, что им на самом деле нужно.
• Аналитик обучает, задает вопросы, слушает, организует и учится. Это сложная работа.
• Не думайте, что любой талантливый разработчик или опытный пользователь автоматически, без обучения, чтения литературы и тренировок, станет профессиональным аналитиком требований. Все эти роли требуют разных навыков, знаний и личных качеств.
• Требования, не содействующие достижению бизнес-целей проекта, реализовываться не должны.

смотрите еще Цитаты из "Совершенный код" С. Макконнелла