16+
ComputerPrice
НА ГЛАВНУЮ СТАТЬИ НОВОСТИ О НАС




Яндекс цитирования


Версия для печати

Модуль поиска не установлен.

Документирование требований к ПО (Часть 1)

05.06.2008

Сергей Крылов

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

Для чего документировать требования?

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

Тогда эксперт стал глубже вникать в содержание наличных документов. И тут его ждало открытие. Прочитав требования от начала до конца, он не понял, что за продукт разрабатывает команда! В документе было много слов, его объем вполне соответствовал серьезности проекта, но только эти слова не складывались в стройную картину.

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

Эксперт указал на обнаруженный источник проблемы. Требования были срочно переработаны в соответствии с рекомендациями эксперта. Для этого их не пришлось серьезно дополнять или усекать. Их лишь внимательно структурировали и немного исправили. Затем проверили тестплан и выявили все недостающие тесты. Результаты не заставили пожалеть о приложенных усилиях. Выпущенный продукт получил самые благожелательные отзывы пользователей.

Спецификация требований неразрывно связана с самим понятием требований. Вспомним определение IEEE. Требование – это:

1. Условие или свойство, необходимое пользователю для решения проблемы или достижения результата.

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

3. Документированное представление условия или свойства, описанных в пунктах 1 и 2.

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

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

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

 

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

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

 

Полнота

Требование является полным, если в нем содержится достаточно информации для того, чтобы его использовать в качестве основы для имплементации. Изначально большинство требований являются полными не более чем на 50%. Лишь немногие к этапу анализа достигают отметки 75%. Чем более эффективен анализ, тем выше полнота требований к этапу документирования. Задача заключается в том, чтобы на этапе документирования это число оказалось равным 100%.

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

 

Правильность

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

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

 

Четкость

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

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

 

Реализуемость

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

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

 

Необходимость

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

  •           требование включено как результат анализа рынка;
  •           источник требования – запрос заказчика или пользователя;
  •           требование порождено особенностями предметной области;
  •           требование является инновацией.

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

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

 

Приоритезированность

Требование приоритезировано, если существует количественная характеристика, позволяющая сравнивать его с другими требованиями. Возможно существование множества шкал для сравнения требований: по важности для пользователя/заказчика, риску имплементации, цене имплементации, востребованности на рынке и т.п. Количественная характеристика может быть выражена как в цифрах (1, 2, 3…), так и в условных обозначениях уровня (high, medium, low…).

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

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

Однозначность

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

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

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

 

Верифицируемость

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

Верифицируемость, как правило, выявляется на этапе документирования, при попытке связать требования с планом тестирования. Но и ранее, при анализе, такие требования как, например, “Система должна безошибочно функционировать 20 лет”, обнаруживаются и перерабатываются.

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

Консистентность

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

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

При наличии неконсистентных требований на этапе проектирования возникают вопросы, которые невозможно решить, не пересмотрев требования. Это отбрасывает проект назад и может привести к дополнительным расходам.

 

Трассируемость

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

Нетрассируемые требования не позволяют: управлять требованиями, связывать их с тест-планом, проектными документами и т.п., корректно составлять расписание работ, принимать быстрые решения.



статьи
статьи
 / 
новости
новости
 / 
контакты
контакты