Лекция 5: Управление требованиями

Виды и свойства требований:

Разделим требования на две большие группы – функциональные и нефункциональные.

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

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

Сформулируем ряд важных свойств требований.

- Ясность, недвусмысленность — однозначность понимания требований заказчиком и разработчиками.

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

- Полнота и непротиворечивость.

- Необходимый уровень детализации.

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

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

- Прослеживаемость — важно видеть то или иное требование в различных моделях, документах, наконец, в коде системы. А то часто возникают вопросы типа – "Кто знает, почему мы решили, что такой-то модуль должен работать следующим образом ….?".

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

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

- Тестируемость и проверяемость — необходимо, чтобы существовали способы оттестировать и проверить данное требование. Причем, важны оба аспекта, поскольку часто проверить-то заказчик может, а вот тестировать данное требование очень трудно или невозможно в виду ограниченности доступа (например, по соображениям безопасности) к окружению системы для команды разработчика. Итак, необходимы процедуры проверки –выполнение тестов, проведение инспекций, проведение формальной верификации части требований и пр. Нужно также определять "планку" качества (чем выше качество, тем оно дороже стоит!), а также критерии полноты проверок, чтобы выполняющие их и руководители проекта четко осознавали, что именно проверено, а что еще нет.

- Модифицируемость. Определяет процедуры внесения изменений в требования.

Варианты формализации требований:

В реальной практике они всегда существуют в виде какого-то представления – документа, модели, формальной спецификации, списка и т.д.

Каждое представление требований выполняет определенную задачу, например, служит "мостом", фиксацией соглашения между разными группами специалистов, или используется для оперативного управления проектом (отслеживается, в какой фазе реализации находится то или иное требование, кто за него отвечает и пр.), или используется для верификации и модельно-ориентированного тестирования. И в первом, и во втором, и в третьем примере мы имеем дело с требованиями, но формализованы они будут по-разному.

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

- Неформальная постановка требований в переписке по электронной почте.

Хорошо работает в небольших проектах, при вовлеченности заказчика в разработку.

Хорошо также при таком стиле, когда есть взаимопонимание между заказчиком и командой, то есть лишние формальности не требуются.

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

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

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

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

- Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.

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

Некоторые ошибки при документировании требований:

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

- Описание возможных решений вместо требований.

- Нечеткие требования, которые не допускают однозначную проверку, оставляют недосказанности, имеют оттенок советов, обсуждений, рекомендаций: "Возможно, что имеет смысл реализовать также…..", "и т.д.".

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

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

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

Цикл работы с требованиями:

Выделение требований (requirementselicitation), нацеленное на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.

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

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

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