Какие бывают требования?

· Функциональные требoвания – требoвания к поведению продукта проекта, отвечают на вопрос «что он должен делать» в тех или иных ситуациях.

· Нефункциональные требoвания – требoвания к характеру поведения продукта проекта, определяют свойства продукта, т.е. как он должен работать. Применительно к этому типу требований часто говорят о показателях качества[1] продукта и об ограничениях продукта.

[1] Согласно стандарту ГОСТ 15467-79 под качеством понимается совокупность свойств продукции, обуславливающих ее пригодность удовлетворять определенные потребности в соответствии с ее назначением. А под показателем качества продукции – количественная характеристика одного или нескольких свойств продукции, входящих в ее качество, рассматриваемых применительно к условиям ее создания и эксплуатации или потребления.

Выделяют различные свойства требований, приведем основные из них:

· Ясность (понятность) – требoвание однозначно понимается Заказчиком и исполнителями. Для этого они должны быть написаны достаточно просто, логично и точно. Например, требование «экспонаты должны соответствовать заявленной тематике выставки и выставлены в трех залах» лучше разделить на два.

· Полнота и единичность – требoвание описывает одну и только одну характеристику, содержит всю необходимую информацию для исполнителей.

· Трассируемость (прослеживаемость) – требoвание не противоречит другим требованиям, полностью соответствует остальной документации.

· Выполнимость – требoвание может быть реализовано в пределах проекта.

· Проверяемость (тестируемость) – существует возможность проверить реализованные требования, например, одним из следующих методов: тест, анализ, осмотр. К примеру, требование «чтобы экспонаты были красивыми» – явно не отвечает этому требованию, а вот «экспонаты должны быть разработаны резидентами Фаблаба» уже проверяемо.

7.5 Источники требований

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

Помимо Заказчика и пользователей в качестве источников требований обратите внимание на:

· Пользователей продукта (явных и потенциальных), их представления и ожидания.

· Обслуживающий и технический персонал.

· Нормативные документы: законодательство, нормативное обеспечение организации (регламенты, положения, приказы).

· Экспертов в предметной области проекта.

· Журналы и отчеты об использовании существующих систем, устройств, процессов.

· Конкурирующие (аналогичные) продукты, а также их исполнители.

· Наблюдения за работой пользователей на их рабочих местах.

· Маркетинговые исследования, опросы, статистические выборки.

· Отчеты об ошибках, жалобы, запросы на усовершенствование.

· Системы, продукты, с которыми необходимо обеспечить интеграцию, и т.д.

7.6 Методы выявления требований

Для выявления требований используются различные методы. Спрашивать у пользователей «Что вы хотите?» бесполезно, в подавляющем большинстве случаев не смогут внятно описать свои пожелания. Поэтому для того, чтобы собрать наиболее качественные требования, рекомендуется сочетать между собой несколько методов. Рассмотрим основные методы выявления требований:

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

2. Анкетирование: позволяет быстро собрать информацию у большого числа респондентов. Важно грамотно составить вопросы и хорошо оформить анкету, чтобы ее было удобно заполнять.

3. Фокус-группы: предназначены для проведения встречи заинтересованных сторон и экспертов по предметной области, чтобы узнать их ожидания и отношение к предложенному проекту.

4. Наблюдения: позволяют вникнуть в обстановку, непосредственно увидеть, как проходит процесс и выполняется сотрудником работа; изучить на месте улучшения, сделанные пользователями. Это особенно полезно в случае, когда заинтересованное лицо не может отчетливо изложить свои требования.

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

6. Бенчмаркинг: используется для выявления лучших практик, изучения аналогичных продуктов.

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

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

7.7 Шаги по разработке требований

Обобщенный алгоритм разработки требований включает:

1. Выявление требований.

2. Анализ требований.

3. Документирование требований.

4. Проверка требований.

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

1. Выявление требований к результату проекта – самый сложный шаг в процессе разработки требований. От того, насколько точно, полно и достоверно собраны требования, зависит реализация всего проекта. Хоть выявление требований – это творческий процесс, но есть ряд методов, которые помогут вам собрать требования (приведены на предыдущей странице).

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

1. Что хотите узнать: перечисление целей выявления требований.

2. Где хотите узнать: перечисление источников.

3. Как будете узнавать: используемые методы, мероприятия.

4. Что хотите получить: список предполагаемых документов, результатов.

5. Когда хотите узнать: назначение исполнителей.

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

· заинтересованные стороны говорят о проблемах, которые уже были обсуждены и зафиксированы;

· информация из различных источников стала повторяться;

· заинтересованные стороны стали предлагать новые характеристики, функции, которые явно выходят за рамки текущего проекта;

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

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

Какие действия происходят на данном шаге:

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

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

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

· Определите совместно с Заказчиком их приоритеты и сроки реализации.

Выбор средств анализа зависит от типа проекта, количества и взаимосвязанности требований. Для небольших проектов достаточно составить список требований в Word и проанализировать его. Для средних и больших проектов требования удобно анализировать и описывать с помощью моделей требований. К наиболее часто используемым моделям обычно относят методы анализа бизнес-процессов, объектно-ориентированного анализа и структурного анализа. В том числе используются методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, eEPC и др.

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

В зависимости от проекта формат документа с требованиями может варьироваться:

· от реестра требований – простого документа, перечисляющего все требования, отсортированные по приоритету;

· до полноценного технического задания – более тщательно проработанного описания, содержащего технические решения.

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

Помимо описания документ с требованиями может включать в себя:

· Критерии приемки результата проекта: набор условий, по которым Заказчик будет оценивать результаты проекта, порядок проведения приемки работ.

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

Приведем некоторые из рекомендаций к формулированию требований:

· Абзацы и предложения должны быть краткими и ясными.

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

· Применяйте визуальное представление информации: списки, таблицы, графики, диаграммы и рисунки.

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

После проверки и исправления замечаний утвердите документ у Заказчика и смело приступайте к реализации проекта.