Назад Оглавление Вперед

4. СТРАТЕГИЯ РАЗРАБОТКИ ДОКУМЕНТА ⌠ТРЕБОВАНИЯ К ПО■

В этом разделе рассматривается накопленный в различных проектах опыт разработки требований к ПО и предлагается практическая стратегия написания документа ⌠Требования к ПО■.

4.1. Обзор накопленного опыта разработки требований

4.1.1. Опыт разработки требований в корпорации АВС Computer

Как вытекает из опыта фирмы АВС Computers [ 3 ], в процессе разработки ПО появляются следующие документы, перечисленные ниже в хронологическом порядке:

Документ ⌠Соглашение о требованиях■ должен содержать первое письменное соглашение между заказчиком и разработчиком о том, что будет сделано и что не будет делаться при разработке и выпуске программного обеспечения. В отличие от него спецификация предполагает наличие более точных и исчерпывающих формулировок и определений. При этом первые два документа содержат информацию о том, что представляет собой изделие; а третий должен объяснять, как изделие устроено и как достигаются установленные для него цели и требования. Все документы имеют схожую структуру для облегчения контроля над проектом, а также для обеспечения прослеживаемости всех технических решений от требований до их реализации. По мере продвижения проекта разделы документа либо просто копируются в соответствующие разделы следующего создаваемого документа либо расширяются описаниями технических решений текущего этапа.
    Ниже приведена общая структура документа ⌠Внешняя спецификация■, с развернутыми комментариями в тех пунктах, которые касаются технической стороны дела (документ также включает экономические, управленческие и другие аспекты, которые не рассматриваются здесь):

1. ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

1.1. Наименование и шифры изделия (полное наименование изделия, сокращенные наименования изделия, шифры изделия и проекта)

1.2. Краткое описание изделия (включая сведения об авторском праве, иерархию документов, с указанием документов вышестоящих уровней)

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

2. ЦЕЛИ

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

3. СТРАТЕГИЯ

3.1. Соглашения относительно представления материала

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

3.1.3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего описания требований)

3.2. Генерируемое программное обеспечение (классифицируется как вспомогательное и порождаемое описываемым изделием)

3.3. Системное программное обеспечение (все остальное ПО, включая ОС, утилиты, пакеты прикладных программ, которое классифицируется как основное, поскольку оно ⌠генерирует■ ПО предыдущего пункта)

Замечание. Причина такой расстановки пунктов состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна опрелделять структуру генератора, а не наоборот. Если все изделие является основным, то в п.3.2. делается пометка ⌠не используется■ и опускаются все его подпункты. Структура подпунктов п.п. 3.2 и 3.3 полностью дублируется и далее для простоты используется нумерация только п.п. 3.3.

3.3.n. Общие характеристики функции ⌠n■.

Если технически затруднительно и неестественно рассматривать изделие как один большой функциональный модуль, то следует привести его функциональную декомпозицию, показав связи между функциями (функциональными модулями) и присвоив каждой функции некоторое уникальное имя ⌠n■. Затем для каждой функции отводится подраздел раздела 3.3 (т.е. 3.3.1, 3.3.2 и т.д.), в заглавии которого используется слово ⌠функция■ с последующим именем функционального модуля. Отметим, что такая функциональная декомпозиция не указывает, как именно изделие будет фактически разбито на программные модули (это составляет содержание документа ⌠Внутренняя спецификация■). Для удобства работы, конечно, полезно иметь некоторое соответствие функционального и фактического разбиения, но это не является требованием и не должно уводить с правильного пути проектирования изделия.

3.3.n.1. Внешние ограничения
3.3.n.1.1. Стандарты (список используемых промышленных стандартов и собственных стандартов предприятия)
3.3.n.1.2. Ограничения на совместимость.
Необходимо рассматривать несколько аспектов совместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и т.п. Специально должна оговариваться совместимость со следующими программными изделиями:

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

3.3.n.1.4. Аппаратные ограничения.
Приводится перечень устройств, необходимых для работы ПО (с указанием минимальной, оптимальной и максимальной конфигурации). Указываются все действующие ограничения на оборудование, например, физические характеристики терминала или требование запрещения использования звукового сигнального устройства.

3.3.n.2. Внешние характеристики

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

3.3.n.2.1. Результаты.
Описываются все выходные данные ПО с точки зрения их функционального содержания и назначения (например, файлы, сообщения, программно устанавливаемые сигналы и прерывания). При этом должны быть рассмотрены все возможные в системе носители и средства отображения информации. Указываются тип, структура, формат, объем, расположение и диапазон изменения. Для всех выходных данных, читаемых людьми (сообщения и отчеты) должны быть приведены образцы.

3.3.n.2.2. Процессы обработки.
Описываются операции, выполняемые ПО в целом или функциональными модулями, рассматриваемыми как ⌠черный ящик■. если обсуждение идет на уровне модулей или этапов разработки, указываются также модули или этапы, требуемые для получения определенной выходной информации. Точно определяются все возможные ошибки, потенциальные условия их возникновения и способы рестарта и восстановления. Подраздел должен описывать инициацию, преобразование данных, все варианты завершения работы (нормального и аварийного).

3.3.n.2.3. Входы.
Описание подобно п. 3.3.2.1

3.3.n.3. Эргономические характеристики.
Замечание. Этот раздел описывает свойства, обеспечивающие надежность, комфорт и продуктивность работы пользователей и операторов, а также вопросы безопасности, секретности, восстанавливаемости после сбоев, мобильности ПО. Остановимся более подробно на двух подразделах: ⌠Надежность■ и ⌠Рабочие характеристики■.

В разделе ⌠Надежность■ (это свойство программы понимается здесь как способность к восстановлению нормальной работы при ошибках и сбоях в работе оборудования) рассматриваются следующие вопросы:

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

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

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

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

4. ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)

4.1.2. Опыт разработки требований ПО для самолета А-7

Полетная программа самолета А-7 ВМС США [ 6 ] должна была входить в состав системы навигации и управления оружием самолета, получая входные данные от датчиков, переключателей, расположенных в кабине, а также от пилота, который вводит их с помощью специальной клавиатуры. Программа управляет несколькими устройствами отображения информации в кабине и производит установку положения нескольких датчиков. Всего к ЭВМ подключены 22 устройства, в числе которых. например, инерционный измеритель скорости и пилотажно-проекционный индикатор. Программа вычисляет навигационную информацию (текущее положение самолета, скорость, курс) и управляет применением оружия.
   Разработчики полетной программы самолета А-7 приводят следующие цели документа ⌠Требования к ПО■:

Суть подхода разработчиков полетной программы самолета А-7 к документированию требований можно выразить в виде трех принципов:

При организации описания интерфейсов с аппаратурой было введено понятие элемента данных как любого входного или выходного параметра, значение которого изменяется независимо от других параметров. Так, на входе программы присутствует барометрическая высота, положения переключателей режима датчиков, сигналы готовности датчиков и т.д. На выходе - координаты маркера положения самолета на индикаторе пилота, команда управления антенной радиолокатора, сигнал управления индикатором ⌠Сбой ЭВМ■ и т.п. Всего бортовая ЭВМ самолета А-7 получала 70 входных элементов данных, и передавала 95 выходных элементов данных. При описании этих данных применялись символические имена элементов данных и их значений (как отдельных, так и групп), специально подготовленные шаблоны и формуляры табличного типа.
   При описании входных данных следует воздерживаться от указаний того, как и когда эти данные используются программой, чтобы избежать каких бы то ни было предположений о функции программы. Входные данные лучше всего описывать как перечень ресурсов, которые можно использовать при решении задачи, не упоминая об эффекте их изменения, который реализуется программой. Выходные элементы данных описываются в терминах воздействия на внешние устройства, избегая любых ассоциаций, не связанных со свойствами аппаратуры (т.е. реализуемых программно).
   При организации описания функций программы необходимо связывать функции с выходными элементами данных: каждая функция определяет значения одного или более выходных элементов данных, и значения любого выходного элемента данных задаются в точности одной функцией. Такой метод описания функций работает для большинства выходных элементов, использование которых носит ограниченный характер. В случае устройств общего назначения, таких как дисплей, можно построить описание так, как если бы для каждого вида информации была отдельная панель на этом дисплее, управляемая отдельной функцией. Необходимо добавить к этим описаниям набор правил, определяющих, какая из функций управляет реально дисплеем в каждый конкретный момент. Такой подход (создание ⌠виртуальных дисплеев■) позволяет разделять решения о том, какие вырабатываются значения и о том, когда они отображаются.
    Далее, функции программы можно подразделить на запрашиваемые и периодические. Каждое исполнение запрашиваемой функции происходит в ответ на некоторое событие. Например, сигнал ⌠Сбой ЭВМ■ включается запрашиваемой функцией при обнаружении ошибки в работе аппаратуры. Периодическая функция (например, функция обновления координат на дисплее пилота) выполняется многократно, и ее не нужно каждый раз запрашивать. Вместо этого, ее можно запускать и останавливать специальными событиями. такое разделение полезно, потому что для периодических и запрашиваемых функций требуется разная информация о режиме исполнения и временных характеристиках. При описании запрашиваемой функции нужно указать события, вызывающие ее выполнение, а вопрос, который следует задавать в отношении временных характеристик, таков: ⌠Какова максимально допустимая задержка между запросом и действием по запросу?■ Описывая периодическую функцию, необходимо задать события, запускающие и останавливающие ее периодическое исполнение и условия, влияющие на ее работу после того, как она запущена. Уместный вопрос о временных характеристиках: ⌠Какова минимальная и максимальная частота повторения этой функции?■
    Опыт рассматриваемой разработки показал, что естественный на первый взгляд подход, при котором выходные значения описываются как математические функции от входных значений, оказался практически не пригоден. Дело в том, что приходится определять некоторые вычисляемые промежуточные значения, которые в свою очередь образуются из других промежуточных значений. В конечном итоге при таком подходе будет фактически описана реализация, что недопустимо для документа требований к ПО. Поэтому предлагается описывать требования, задавая выходные значения в виде функций от условий работы самолета и от событий, происходящих при этом. Напомним, что события возникают в некоторые моменты времени, а условия действуют в течение некоторого промежутка времени. Условия можно записать в виде логических предикатов, используя входные элементы данных, или уже некоторые макроопределения, происходящие от этих данных. Тогда событие привязано к моменту изменения некоторого условия (т.е. ставшего истинным, будучи до этого ложным или наоборот) и связано с некоторым изменением внешнего мира, о котором программа узнает посредством анализа входных данных.

   Хотя каждая функция зависит лишь от небольшого подмножества всего множества возможных условий, для упрощения описания функций следует объединять отдельные условия в группы. Для этой цели служит понятие режимов, определяемых как классы состояний системы. Поскольку при переходе из режима в режим функции изменяются гораздо сильнее, чем в пределах одного режима, соответствующее ⌠порежимное■ описание функций оказывается проще для понимания, чем общее описание. Для точности и полноты описания применялись таблицы условий (описывающие выходные значения периодических функций в зависимости от режимов и условий внутри режима) и таблицы событий (описывающие моменты запроса на запрашиваемые функции и моменты запуска/остановки периодических функций; а также действия, производимые по событиям).

   Чтобы охарактеризовать требуемую реакцию системы на нежелательные события, полезно составить общий список возможных нежелательных ситуаций, например, такой:

1. Отказы ресурсов

2. Ошибки во входных данных

3. Ошибки во внутренних данных

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

4.2. Требования стандартов

4.2.1. Стандарт DO-178B в части разработки требований к ПО

Разработка требований к ПО, согласно стандарту DO-178B, охватывается более общим процессом разработки ПО, состоящим из следующих этапов:

В соответствии со стандартом DO-178B в процессе разработки ПО вырабатывается по крайней мере один (а в ряде случаев и больше) уровень требований к ПО. Требования высокого уровня получаются непосредственно из анализа требований к системе и анализа архитектуры самой системы и должны включать в себя:

Эти требования далее обычно развиваются на этапе проектирования ПО, формируя последующие уровни требований более низкого уровня. Однако, если исходный код генерируется непосредственно из требований высокого уровня, то налицо всего один уровень требований, что дает возможность рассматривать их и как требования низкого уровня. В этом случае к ним применимы соответствующие принципы и правила их формирования.
    На этапе проектирования ПО (если он есть) определяются как архитектура ПО, так и требования низкого уровня. Разработка архитектуры ПО заключается в принятии ряда последовательных и взаимосвязанных решений о структуре ПО, имея в виду как собственно программные модули так и структуру используемых данных. Разработка требований низкого уровня к ПО тогда сводится по сути к формированию требований уже к отдельным программным модулям и их интерфейсу с другими модулями. В такие требования могут включаться также требования на динамическое взаимодействие модулей между собой в рамках некоторой операционной системы или работы иной организующей программы (если она есть). Из требований низкого уровня без какой-либо дополнительной информации может быть непосредственно реализован исходный код программы.
     Каждая из составляющих фазы разработки ПО может порождать производные требования - требования, прямо не прослеживаемые к требованиям высокого уровня. В качестве примера можно привести необходимость программ обработки прерываний для многих систем реального времени. Введение системы прерываний обычно напрямую не связано ни с одной из функций, требуемых потребителем, однако их реализация на выбранном компьютере без такого механизма может быть затруднена или не осуществима совсем. Производные требования могут включаться в состав требований как высокого, так и низкого уровня.
     Исходными данными для этапа разработки требований к ПО согласно стандарту DO-178B являются следующие документы:

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

4.2.2. Основное содержание документа ⌠Требования к ПО■

Документ ⌠Требования к ПО■ определяет требования высокого уровня, включая и производные требования, если это необходимо. Эти данные должны включать (но не ограничиваться этим):

Несмотря на то, что стандарт DO-178B достаточно определенно описывает необходимое содержание документа ⌠Требования к ПО■, можно привести ряд практических рекомендаций, разъясняющих необходимые требования к документу в терминах, более привычных для программистов. Так, более сбалансированный, более удобный в использовании и при этом полностью соответствующий стандарту список требований к ПО может выглядеть так:

4.3. Обсуждение общих проблем документирования разработки ПО

4.3.1. Необходимость ведения проектной документации

Вполне возможно, что небольшую систему удастся спроектировать ⌠за один присест■, описать проект в одном документе и самим же построить спроектированную систему. Но для больших и сложных систем так не выходит. Помимо того, что в проект вовлекается множество людей, необходимо еще и написать множество документов, удовлетворяющих самым разным запросам. Среди всей значительно отличающейся по содержанию, стилю и терминологии документации документы, относящиеся к разработке системы формируют иерархию или пирамиду, которая при взгляде сверху вниз описывает дизайн в более и более мелких деталях. При этом многие документы высокого уровня пишутся с мысленным учетом специфических деталей дизайна на основе уже проведенных исследований и рабочих материалов предыдущих проектов.
    Документы в пирамиде могут быть рассмотрены в двух смыслах, что обычно отражается и в их названии: как спецификация того что было разработано и как требования для дальнейшей разработки. Просто ⌠Спецификация■ подчеркивает, как много дизайна уже проделано, а ⌠Спецификация требований■ отражает, как много еще предстоит сделать. Если возникает проблема и дизайн должен измениться, необходимо сохранить в архиве оригинальный вариант дизайна и смысл каждого изменения. В этом контексте дизайн может выглядеть как иерархия решений, а спецификация просто описывает их.
     На самых ранних стадиях проекта первая цель документов - позволить руководству проектом оценить необходимые ресурсы. Ведение проектной документации имеет далее несколько различных целей:

4.3.2. Информационное содержание проектной документации

При первом взгляде может показаться, что целая иерархия документов генерируется декомпозицией одного единственного документа - Спецификации Требований (примерно так же, как проводится функциональная декомпозиция в методе структурного анализа). Между тем, обычная спецификация требований для проекта занимает порядка 100 страниц, в то время как нижний уровень проектной документации - несколько тысяч, т.е. явно содержит больше информации. Поэтому можно сделать вполне очевидный вывод, что в процессе разработки добавляется новая информация. Т.о., разработка состоит не столько в произведении функциональной декомпозиции, сколько в производстве решений, добавлении информации, создании порядка из беспорядка. И тогда одна из главных функций спецификации состоит в отражении этой информационной деятельности.
   Требования для нового продукта или системы редко приходят в жизнь как точные, хорошо продуманные идеи. Поначалу имеется только несколько человеческих ⌠нужд■, которые осознаются и выражаются в терминах существующих известных вещей. Дизайн, в самом широком смысле, это работа по изучению этих ⌠нужд■ и производству продукта для их удовлетворения.
     На первый взгляд необходимо только, чтобы нуждающееся лицо (пользователь) записало то, что оно хочет, в Спецификацию Требований. Например, пользователь выражает нужду в ⌠управляющем центре■, который должен ⌠управлять движением и.т.п.■. Затем некто (инженер, проектировщик), получив эту спецификацию, может построить требуемое.

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

   Описание проблемы пользователем не должно предполагать какие-либо решения (возможно такие решения могут оказаться недоступными для современной технологии). Упрощенно можно полагать, что после написания Спецификации Требований мы видим мир с описанием нового продукта и меньшим числом проблем. Мы не можем сказать в деталях, что находится внутри квадрата ⌠центр управления■: это относится к области проектных решений. Мы можем только определить это в терминах нового поведения окружающего мира и взаимодействия нашего нового продукта с окружающим миром. Хотя мы и приняли несколько решений, мы еще не спроектировали наш ⌠квадрат■. Выполняемые им (вследствие наших решений!) функции существуют лишь как высокоуровневые, человеческие идеи. И эти идеи невозможно просто проанализировать с целью получения низкоуровневых деталей. Анализ является важной компонентой Спецификации Требований. Но это только одна компонента, и необходимо не путать ее со следующей фазой: проектными решениями. Мы можем анализировать только вещи, которые существуют, т.е. мир ⌠до■ новой системы. Мы не можем анализировать вещи которые являются только идеями в сознании потребителя или разработчика. Однако мы нуждаемся в большей информации, и она может придти только от пользователя. Если он хочет, чтобы дизайн был успешным, он должен конкретизировать свои нужды, но не как детали дизайна внутри ⌠квадрата■, но в терминах цели, для которой этот ⌠квадрат■ задуман в будущем пользовательском мире. Так, система будет должна ⌠хранить деньги■, ⌠уменьшать время доставки■ и.т.д.
<   Спецификация Требований не является полным описанием продукта; это перечисление целей и намерений, имеющее предполагаемую систему на низшем уровне описания и неограниченное чем либо сверху. Напротив, работа проектировщика не анализ требований, а синтез дизайна. Проектировщики должны делать решения. И хотя эти решения происходят как отклик на требования пользователя, они не содержатся в последних. Проектировщики будут синтезировать проект, т.е. сделают множество решений, которые станут своеобразным мостом между целями пользователя и конечными деталями управляющего центра.
     Итак, смысл декомпозиции требований в проект заключается в том, что проектные решения образуют структуру; а сам метод структурной декомпозиции помогает нам при этом организовать и документировать наши проектные решения.
     Если мы сгруппируем решения в соответствующие документы, то немедленно увидим, почему документы верхнего уровня тоньше, чем нижнего: они содержат немного решений. Также становится понятным, почему Спецификация Требований сама может быть достаточно объемной: она содержит не столько решения, сколько обзор окружающего систему внешнего мира.
     Если можно проследить каждое предложение в требованиях в множество решений и каждое решение в множество предложений в требованиях, то в системе проектной документации имеется информационный баланс. Сложное требование, скажем, будет иметь соответственно большее число решений в проектной спецификации.
     Хотя теоретически это верно, на практике нет дизайна полностью оригинального. Производитель будет всегда пытаться продать продукт, который уже был разработан. В действительности требование не пытается охватить все детали дизайна, а вместо этого ссылается на другие документы. Например, если мы покупаем машину, продавец получает наши требования в терминах размера вашей семьи, величины вашего дохода, вашего социального положения и.т.д. Все это транслируется в простую формулу типа ⌠Модель А, 4 двери, 1600 куб.см■. И это является Спецификацией Требований■, которую получают на заводе.
    Ясно, что такая информация не претендует на перечень всех деталей, необходимых для постройки машины. Вместо этого просто называется один из продуктов, выпускаемых заводом, что может быть закодировано всего шестью цифрами. Реальная Спецификация Требований, по которой строится машина, является более длинным документом (или их множеством). Это скрытый документ, с его проведенными исследованиями и отчетами, который и используется для постройки машины. Все требуемые изменения в процессе постройки могут быть просто перечислены в ⌠Спецификации Требований Пользователя■. Тогда более общий принцип информационного баланса заключается в том, что Спецификация Требований должна содержать всю новую или нестандартную для проектируемой системы информацию.

4.4. Общий процесс анализа текстовой проектной документации и формулировки требований

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

4.4.1. Идентификация требований и ограничений

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

4.4.2. Рационализация повторяющихся требований и ограничений

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

4.4.3. Устранение неоднозначности

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

   ⌠3.6.7-1. Самолет должен иметь достаточную надежность.
Замечание. Достаточная надежность означает, что MTBF больше чем 10000 часов.■

4.4.4. Классификация требований/ограничений

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

4.4.5. Определение ответственных за выполнение

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

4.4.6. Примеры

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

1. ⌠Проверка диапазона величины X включается при нажатии клавиши ⌠ВК■ на клавиатуре■.
   Неясно, при любом ли нажатии указанной клавиши производится эта операция. Кроме того, неясно, выполняется ли эта операция ⌠автоматически■ аппаратными средствами клавиатуры или ее приходится поддерживать программно. Лучше формулировать более конкретно таким образом: ⌠Проверка диапазона величины X должна выполняться программой обработки прерывания от клавиатуры после окончания набора величины X на клавиатуре и нажатия клавиши ⌠ВК■■.

2. ⌠Сигнал А устанавливается в нулевое значение■.
   Неясно, имеется в виду физический или логический нуль, который может отличаться от физического. Также явно не определено, чья это функция. Лучший вариант выглядит так: ⌠Сигнал А должен устанавливаться программой обработки прерываний в нулевое логическое значение. Примечание. Уровни логических значений соответствуют их физическим величинам, а именно:...■.

3. ⌠Выходные данные будут заполнять состоять из одного полного блока записей■.
   Неясно, сколько записей могут входить в полный блок записей.

4. ⌠Программа мониторинга должна обнаруживать и обрабатывать ошибочные ситуации: переполнение, деление на нуль, достижение конца файла и т.д.■.
    Любое перечисление в рамках требований, конечно, не должно включать слова типа ⌠и т.д.■. Кроме этого слово ⌠обрабатывать■ без разъяснений его смысла также недопустимо.

4.5. Анализ характеристик качества содержания документа

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

4.5.1. Полнота

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

   Далее, проектные спецификации в принципе могут быть полны, если мы описываем управляющий центр, телефоны, компьютеры, программы до самой последней детали. Однако, на практике мы даже не пытаемся это делать. Спецификации содержат детали, но описывают только их новые, нестандартные особенности, отсылая за остальным к уже существующим описаниям. Остальная часть системы специфицируется по тому же принципу, как и ранее автомобиль: ⌠Компьютер модели А, 1 Мбайт, 4 диска■. Однако, как только мы определяем конечное число информации, мы вынуждены считать при этом, что весь бесконечный остаток ⌠не имеет значения■. Список вещей, которые должны были бы специфицироваться, бесконечен. То, что мы выбираем для описания, определяется скорее не ⌠полнотой■, а принципом ⌠наибольшей отдачи■, который предполагает малоценным описывать детали после некоторого предела. Где этот предел находится, зависит от многих факторов, и определяется для каждого проекта независимо и во многом субъективно.

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

4.5.2. Формальные языки и смысл

Выше было показано, что не стоит пытаться наполнять спецификацию всеми деталями, оставляя последние во вспомогательных документах, отражающих накопленный производителем опыт. Вместо описания всех особенностей ⌠стиля■, ⌠мощности■ и ⌠размера■ автомобиля, мы говорим ⌠Модель А, 4 двери, 1600 л.с.■. Это язык формальной спецификации, который превосходит традиционный язык в смысле формального синтаксиса и семантики. Каждый элемент определяется во вспомогательных документах, которые доступны как пользователю, так и производителю.
    В наши дни возможно даже выполнить компьютерный анализ таких языков. Изготовитель автомобиля в состоянии при этом проанализировать спецификацию пользователя на предмет согласованности (и полноты) и вроде бы ничто не мешает направить результат прямо в автоматическую производственную линию. На самом деле своим формальным описанием мы только доопределяем небольшие изменения в уже готовых конструкциях, формальные элементы просто указывают на другие документы, где содержатся реальные спецификационные детали. Только эти документы и придают смысл нашим формальным элементам. Синтаксис языка контролируется проектными инженерами, которые ограничивают его в множестве автомобилей, которые уже разработаны и проверены.
   Если мы хотим получить систему с новыми, непроверенными свойствами, мы не можем так поступать. Мы не можем просто определить ⌠управляющий центр■ т.к. эти слова не определены во вспомогательных документах. Только пользователь знает их смысл, пока система еще не спроектирована. В процессе дизайна, мы можем произвести множество формальных описаний на базе уже известных элементов, таких как компьютеры и телефоны. Но новые особенности, которые делают эту систему отличащейся от других, не могут быть описаны этим путем. Какие бы элементы мы не использовали, слова могут быть только или уже определенными, или понимаемыми со ссылками на спецификацию требований. И это возвращает нас к пониманию посредством мира пользователя. Смысл наших слов остается в конечном счете в рамках обычного языка и человеческих идей.
     Предположим далее, что мы запрашиваем ⌠Модель А, 4 двери, преобразованый для инвалидов■. Первые два параметра являются формальными ссылками на базовые элементы, однако третий неформален и должен быть разъяснен пользователем. Но мы не можем просто просто отделить первые две части спецификации, запуская ⌠Модель А, 4 двери■ в производственную линию и проектируя сами остальное. Присутствие новой особенности ставит весь наш дизайн под сомнение. Мы не можем далее просто конвертировать формальные параметры в строку цифр для компьютерной обработки, нам следует изучить их определения. И они также остаются в конечном счете в рамках обычного языка и неограниченной сложности реальных объектов.
     Конечно элемент ⌠4 двери■ может быть вполне понятен, но только в том смысле, какой дает нам мысленная картинка автомобиля. Слова содержат зародыши идей, ⌠смысловых зацепок■ (semantic hooks) которые сцеплены в множество неформальных изображений в человеческом сознании. И если слова выбираются тщательно, они могут иметь большое значение. Они позволяют нам думать в высокоуровневых идеях, предусматривая ⌠рычаги■ для манипулирования реальными, нижележащими определениями. Но мы не должны смущаться неформальной картиной при определении реального объекта. Конечный автомобиль, после преобразования, может иметь 3 или 5 дверей - но он будет все еще помечен как ⌠4-дверный■ на производственной линии. Разрешая такие ⌠смысловые зацепки■ формальных слов, мы стараемся обсуждать неформально в интересах эффктивного взаимодействия.
    Использование этих ⌠зацепок■ - уже известная техника в программировании, где идентификаторы носят ⌠осмысленные■ имена. В этом случае имена эквивалентны комментариям в программе, и мы можем продемонстрировать это редактированием всех имен в случайные текстовые строки перед компиляцией. Такой текст программы станет бессмысленной для человека, однако это не повлияет на ее выполнение. Это демонстрирует разницу между формальной записью на языке программирования и намеченным реальным эффектом от компьютерной системы отражаемого в именах переменных.
     Конечно, как только проект будет закончен, все слова станут формально определенными уже простым указанием на законченную систему. Но в это время все проблемы уже решены и большая нужда в строгости и взаимодействии отпадет. Не является большим достижением формальное описание уже спроектированной системы. Сказанное не означает, что мы не можем использовать обозначения математики как помощь в описании взаимоотношений. Но мы должны помнить, что в рамках разработки технической документации ⌠формальность является в лучшем случае аналогией и в худшем - косметикой■.

4.5.3. Избыточность и неоднозначность

Мы пришли к заключению, что смысл любой спецификации содержится в конечном счете в словах обычного языка. Но что эти слова означают? Сами по себе слова не имеют смысла. Смысл вносится при совместном извлечении группой слов подходящего отклика в человеческом сознании. Чтобы дойти до широкой аудитории или достичь более точного смысла мы нуждаемся в большем числе слов без ограничения. Многие очень простые идеи требуют целых книг для из разъяснения. просто потому, что они противоречат нашему накопленному опыту.
    Это представляет избыточность и неоднозначность в новом свете. В буквальном (тривиальном) смысле, избыточность означает наличие вещей, которые не являются необходимыми, а неоднозначность означает более чем один возможный смысл. Мы можем исключить и то и другое из документации для большей краткости и формальности. Но если мы сделаем это просто путем выбрасывания разъяснений, то мы выбросим и смысл тоже, ⌠выплеснем с водой и ребенка■. В итоге мы получим голые математические уравнения без неоднозначностей и без смысла.
     На самом деле мы хотели бы удалить неоднозначность, но только не за счет общего смысла. Если мы хотим быть понятными, мы должны сами и разъяснить, т.е. сказать одну вещь разными способами. Мы не просто пишем столько, сколько необходимо для разъяснения, но мы пишем столько, сколько необходимо для понимания. Спецификация, которая разъясняет что-либо двумя способами, подобна дублированной компьютерной системе, что защищает от целого класса ошибок. Итак, мы должны писать так много, как наиболее ценно для понимания.

4.5.4. Общие рекомендации

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

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

4.6. Переход от анализа системных требований к разработке требований к ПО

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

Шаги формирования архитектурной модели системы представлены ниже:

Образно говоря, сначала из системных требований вычленяются функциональные и управляющие требования, которые формируют стройный ⌠скелет■ модели обработки данных/управления, затем этот скелет ⌠обрастает■ в связи с наличием нефункциональных (в т.ч. технологических) требований, не теряя стройности, придаваемой все время указанным ⌠скелетом■, и превращаясь в конце концов в архитектурную ⌠физическую■ модель системы.
   Если модель системных требований можно считать технологически независимой, то архитектурная модель является уже технологически зависимой и находится не в области требований, а в области проектирования системы. Тем не менее мы вынуждены сделать этот шаг до разработки требований на ПО. Объяснение этому однако вполне естественно в рамках иерархического подхода к любым системам:

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

Рассмотрим основные особенности архитектурной модели в сравнении ее с функционально-управляющей моделью:

Введение в модель интерфейсных требований может интерпретироваться, например, как отщепление от терминатора соответствующей интерфейсной функции, которая получает от терминатора те же данные, но только в другом формате, более привязанном к физической реализации.
   В общем случае, процесс создания архитектурной модели требует учета и функциональных и управляющих требований для архитектурных модулей, производства проектных решений в части перераспределения требований, оценки полученных результатов, и как правило, носит итерационный характер.
     После построения архитектурной модели необходимо решить, как конкретные модули будут реализовывать предписанные им требования: только аппаратно, только программно (мы не заботимся в этом случае о базовом вычислителе, обычно это стандартный готовый компьютер), или аппаратно/программно. Следует отметить, что последний случай на самом деле на более нижних уровнях декомпозиции сводится к первым двум, так что достаточно разделять только аппаратные и только программные требования. После этого системного проектного решения о разделении архитектурных модулей на аппаратные и программные и начинается, собственно, фаза разработки требований к ПО (базирующемся на этих программных архитектурных модулях). Рекомендуется ⌠не забегать вперед■ и не начинать разработку программных (и аппаратных) требований, пока полностью, т.е. до самого нижнего уровня, не закончен анализ системных требований. Аналогичную рекомендацию можно дать при разработке программной (и аппаратной) архитектуры.
     В практике разработки не очень больших встроенных централизованных систем обработки данных как правило только один архитектурный модуль, связанный с наличием встроенного компьютера отвечает за программные требования. Напротив, в децентрализованных системах (начиная уже от персонального компьютера с ⌠интеллектульными■, т.е. на базе микропроцессора, контроллерами внешних устройств и до систем управления космическими аппаратами) может быть несколько или даже много таких модулей. Требования к ПО разрабатываются отдельно на каждый такой архитектурный модуль.

4.7. Процесс разработки требований к ПО

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

Пока не существует общепринятого удобного способа графически изобразить все типы структур программной архитектуры на одной диаграмме. Можно порекомендовать на высших уровнях программной архитектуры пользоваться аналогичными CDFD диаграммами обмена векторами данных между модулями посредством физических каналов, на средних уровнях переходить к схемам Константайна [ 10 ], а архитектуру отдельных программных модулей описывать псевдокодом или, если она является логически сложной - на языке обычных блок-схем.
     Информационная модель (в виде различных диаграмм, миниспецификаций и словаря данных) несмотря на всю ее важность для успеха разработки, может служить лишь приложением или неосновной частью документа. Основной частью документа, как вытекает из его названия, являются сами требования. Поэтому после завершения анализа требований к ПО необходимо составить документ ⌠Требования к ПО■, удовлетворяющий, например, стандарту DO-178B.

Назад Оглавление Вперед