Разработка программного обеспечения основывается на требованиях - ожиданиях пользователей к будущей функциональности. Требования бывают очень разные по сути, составу, форме и качеству. Поэтому очень важно правильно называть и использовать требования разного сорта.
В Devprom ALM мы выделяем три основных уровня требований:
| Уровень заказчика, пользователя или их представителей |
Первичные требования - пожелания, заявки, запросы на изменения, хотелки. Это неструктурированные, неполные и даже противоречивые требования, которые поступают команде из различных источников. Часто такие требования сформулированы вольным текстом или записаны в формате пользовательских историй. Принципиальное отличие первичных требований от остальных - в них содержатся как требования к функциональности, так и изменения к функциональности. Другими словами, по набору первичных требований крайне сложно получить целостное описание функциональности всей системы. |
| Уровень анализа, проектирования и моделирования |
Бизнес-требования и системные требования (функциональные и нефункциональные, НФТ), которые целостно и непротиворечиво описывают бизнес-процессы и требования к разработке программной системы. Эти требования самого высокого качества, поскольку готовятся специально обученными людьми. Системные требования могут подразделяться на варианты использования, НФТ, UML-модели, макеты пользовательского интерфейса и т.п. В качестве форматов документирования обычно применяют: BRD (документ бизнес-требований), бизнес-кейс, SRS (спецификация системных требований), ТЗ (техническое задание) и т.п. |
| Уровень разработчиков, тестировщиков и технических писателей | Задачи по реализации требований (целиком, частями или целыми документами) называются доработками. В доработке записано что необходимо реализовать или какие выполнить изменения в ранее реализованном требовании, когда и кому это сделать и т.д. Тестировщики также используют доработки для проверки реализации требований. |
Важно также отличать тип требования от формата, в котором оно задокументировано. Например, ТЗ (техническое задание) в себе содержит множество требований разных типов и общую информацию. Варианты использования (Use Cases) могут быть записаны в формате, предложенном А. Коберном или предложенном в процессе OpenUP (Rational Unified Process) и еще несколькими популярными вариантами. Вам необходимо самостоятельно определиться, каким именно образом эффективно документировать требования на ваших проектах.
В зависимости от сложности предметной области, сложности системы и квалификации исполнителя, описанные уровни требований могут пересекаться. Например, команда разработки может эффективно работать и с первичными требованиями.
Ниже приводятся современные способы выявления и сбора первичных требования.