Что такое требования

Требования к ПО

Требование — это пригодное для практического применения представление проблемы, которую нужно решить, или возможности, которую нужно использовать. Требования акцентируют внимание на ценности, которую можно получить при их реализации. Требования можно представить в виде документа, набора документов или в ином соответствующем обстоятельствам виде (The Business Analysis Body Of Knowledge (BABOK) Guide — свод знаний по бизнес-аналитике, составляемый Международным институтом бизнес-анализа IIBA).

Требование — это определение того, что должно быть реализовано. Оно описывает поведение системы, её свойства или атрибуты, которые могут стать ограничением для разработки (Ian Sommerville & Pete Sawyer).

Требование — это всё, что влияет на проектирование ПО (Brian Lawrence).

• Требование описывает решение проблемы. То есть требование — следствие возникновения определённой проблемы, которую оно должно решить.
  Например, пользователи Chatty не могут добавить незнакомые слова в личный словарь, хотя они нужны им для дальнейшего изучения. В этом случае требование, которое передаёт ожидания пользователей от ПО, звучит так: «Приложение Chatty должно позволять пользователям сохранять слова для дальнейшего изучения».
  А если Даня предложит добавить в Chatty, например, взаимодействие с умным домом, это не будет требованием, ведь он не является пользователем или заказчиком, непонятна цель такого нововведения.
• Требование применимо для практического использования и должно быть реализовано. Таким образом, требованиями не могут быть предположения, пожелания или намерения. Требование содержит конкретику — что именно нужно сделать.
  «Приложение Chatty должно поддерживать режим для слабовидящих» — это требование, которому должно соответствовать ПО.
  А слова: «Наверное, приложение Chatty должно поддерживать режим для слабовидящих, но это не точно. Возможно, слабовидящие не пользуются нашими продуктами» — это ещё не требование, лишь предположение.

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

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

• Физические ресурсы, необходимые команде разработки, например: рабочее помещение, оборудование и прочее.
• Потребность в обучении персонала.
• Проектную документацию, в том числе руководство пользователя, и документацию для технической поддержки.
• Инфраструктурные изменения, которые необходимо внести в операционную среду ПО.
• Требования и процедуры для установки, конфигурирования, тестирования и выпуска нового продукта, а также для перехода со старой системы на новую систему.
• Требования по сертификации продукта, его соответствие требованиям регулирующих органов, правовой защите (патенты).
• Внутренние документы компании: её политика, процессы, структуры и прочее.
• Соглашение с клиентами об уровне обслуживания (Service Level Agreement — SLA). Например, гарантийное обслуживание.

Где описаны требования к проекту

Почему важно разрабатывать качественные требования к ПО

• Недопонимание между заказчиком и командой разработки.
  Допустим, вы приготовили «Наполеон», как и хотел посетитель кондитерской. Однако покупатель всё равно остался недоволен. Он хотел «Наполеон» со взбитыми сливками, а вы сделали его с масляным кремом. С требованиями так же — ваше видение и видение заказчика могут сильно отличаться, поэтому важно на берегу прояснить все детали.
• Бессистемное общение с заказчиками.
  У вас заказали трёхъярусный ванильный свадебный торт. Через некоторое время вам позвонил жених и уточнил, что два нижних яруса нужно сделать в виде клубничных капкейков. Затем позвонила невеста и сказала, что они передумали и хотят вернуться к первоначальному варианту. Когда вы отдали паре торт, молодожёны расстроились — ведь вернуть они хотели только формат, но не вкус, а вы сделали ванильный торт без добавления клубники. Похожая путаница может случиться и с требованиями к ПО, особенно если у вас несколько заказчиков и общение с ними происходит спонтанно — без чёткого плана.
• Ошибки документирования требований к ПО.
  У вас новый заказ. На этот раз вам нужно приготовить торт с надписью «С днём рождения!». Вроде всё просто, но вы забыли, как зовут именинника, и не записали пожелания заказчика. Фиксировать пожелания — особенно актуально для требований. Их будут изучать и другие члены команды разработки, а они могли даже не видеть заказчика. Подробности нужно документировать, даже если на первый взгляд они кажутся очевидными.

Стоимость внесения изменений в ПО или устранения программной проблемы увеличивается пропорционально этапу, на котором вносятся изменения или исправления (Barry W. Boehm, профессор, специализирующийся на программном обеспечении).

Подведём итоги

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