Исключение информации, относящейся к проектированию

Исключение информации, связанной с управлением проектом

Дилемма требований: что или как

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

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

Бюджет тоже может выглядеть как требование; тем не менее это информация другого рода. не удовлетворяющая нашему определению и, следовательно, не относящаяся к системным или программным требованиям. Бюджет — важная информация, особенно когда разработчики решают, какую стратегию реализации избрать, поскольку некоторые стратегии могут быть слишком дорогостоящими, а время их выполнения слишком длительным. И все же это не требование. Аналогично описание процедур тестирования или приемки (с помощью которых мы будем определять, что требования действительно выполнены) также не удовлетворяет определению и, следовательно, не является требованием.

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

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

Исключить из требований детали, относящиеся к управлению проектом и тестированию, достаточно просто. Но исключение деталей проектирования и реализации обычно гораздо более сложная и тонкая работа. Предположим, что первое требование в табл. 23.1 сформулировано следующим образом: "SR63.1. Информация об обнаруженных дефектах будет предоставляться в виде отчета-гистограммы, написанного на Visual Basic, причем основные причины будут откладываться по оси х, а количество дефектов — по оси у" (рис. 23.2).

Рис. 23.2. Отчет-гистограмма

Хотя указание Visual Basic в качестве языка написания программы является достаточно явным нарушением наших рекомендаций (поскольку оно не представляет ни ввод, ни вывод, ни функцию, ни атрибут поведения), полезно задать вопрос: "Кто принял решение, что гистограмма должна быть реализована на Visual Basic, и почему оно было принято?" Возможны следующие ответы.

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

• Это может быть указание пользователя. Опасаясь, что разработчики могут применить некую более дорогостоящую и менее доступную технологию, пользователь решает, что технология VB — доступная и относительно дешевая, и хочет, чтобы использовали именно ее.

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

Если технический разработчик решил включить упоминание о Visual Basic, поскольку просто предпочитает данный язык, оно, бесспорно, не является легитимным элементом списка требований. Если это требование предложено пользователем, ситуация несколько иная. Если клиент отказывается платить за систему, написанную не на Visual Basic, лучше всего трактовать подобное пожелание как требование, хотя мы поместим его в специальный класс, называемым ограничения проектирования, так что оно 6удет отделено от обычных требований, описывающих только внешнее поведение. Тем не менее это именно ограничение реализации, налагаемое на команду разработчиков. (Кстати, если вы думаете пример нереалистичен, напомним, что до конца 1990-х обычным требованием Министерства обороны США к разработчикам программного обеспечения было "создавать системы, используя язык Аdа".)

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

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