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

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

• документ с требованиями должны быть удобным для чтения;.

• наборы требований должны быть удобными для работы с ними.

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

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

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

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

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

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

Именно поэтому написание и анализ (рецензирование) требований рассматриваются нами вместе в одной главе.

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

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

Отправной точкой при разработке требований является определение заинтересованных сторон (stakeholders), как это показано в таблице 4.1.

Таблица 4.1 Заинтересованные стороны (stakeholders) для требований

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

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

Возможность.

• Возможность однозначно идентифицировать каждое положение требования.

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

- по важности.

- по типу (например, функциональность, производительность, ограничение, безопасность).

- по срочности (дата реализации).

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

- статус рецензирования (анализа).

- статус удовлетворения.

- статус проверки.

• Возможность оценивать требование с разных сторон, таких как:.

- информации о производительности.

- стратегия проверки.

- критерии тестирования.

- рациональность.

- комментарии.

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

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

• Возможность установления связей между требованиями и легкого перехода по этим связям между требованиями.

4.3 Разработка структуры требований.

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

Создание хорошей структуры требований может помочь:.

• минимизировать общее количество требований;.

• лучше осмыслить большой объем информации;.

• отыскать наборы требований, относящихся к определенной теме;.

• выявить пробелы и повторения;.

• исключить конфликт (противоречия) между требованиями;.

• управлять этапами реализации (например, вначале отложенных требований);.

• отклонить малоинформативные требования;.

• оценить требования (напр., с точки зрения стоимости или времени реализации);.

• повторно использовать требования в последующих проектах.

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

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

• декомпозиция целей и возможностей в пользовательских сценариях;.

• функциональная декомпозиция в диаграммах потоков данных;.

• декомпозиция состояний системы в диаграммах состояний.

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

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

К такого рода текстам может относиться:.

• Сопроводительная информация, которая помогает правильно позиционировать требование в контексте документа;.

• Описание внешнего окружения системы или, как это часто называют, «знания о предметной области»;.

• Определение границ требований (что включать, а что нет - т.е. границы проекта);.

• Определение терминологии, используемой в документе;.

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

• Характеристика заинтересованных сторон;.

• Краткое описание моделей, используемых для получения требований;.

• Ссылки на другие документы.

4.4 Понятие о ключевых требованиях.

Многие организации начинают применять концепцию «ключевых требований» практически уже на уровне пользовательских требований.

Такие требования, часто называемые ключевыми пользовательскими требованиями KURs (key user requirements) или ключевыми показателями производительности KPIs (key performance indicators), являются небольшой «выжимкой» из общих требований, описывающих суть системы (ее основные функций).

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

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

Джордж сказал: - «... Нужно думать не о том, что нам может пригодиться, а только.

о том, без чего мы никак не сможем обойтись».

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

Если решение не предполагает возможность (функцию, опцию, т.д.), стану ли я в этом случае его приобретать?.

или то же, но на системном уровне:.

Если система не обеспечивает, будет ли система все еще нужна мне?.

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

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

4.5 Использование атрибутов.

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

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

[SH234] Система управления скорой помощью должна быть способна принимать до 100 ста вызовов одновременно

Рис 4.1 Атрибуты требования.

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

На рис. 4.1 показан пример требования [SH234] с присущими ему атрибутами.

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

В таблице 4.3 в качестве наглядного примера, иллюстрирующего вышесказанное, приведены те категории атрибутов требований, которые использовались английским подразделением INCOSE (The International Council on Systems Engineering), работавшим над одним из проектов.

4.6 Связанность и согласованность требований.

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

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

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

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

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

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

4.7 Важность требования.

Некоторые требования можно отнести к категории «не обсуждаемых».

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

Соответственно, другие требования могут обсуждаться и корректироваться.

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

Оценить степень важности (удовлетворенности) требования может быть само по себе трудной задачей. Возможно, что для предыдущего примера достижение показателя в 75 одновременно работающих пользователей будет приемлемой величиной, а вот любая величина ниже 50 будет уже категорически неприемлема, но показатель в 200 пользователей скорей всего будет очень хорошим результатом, который для заказчика будет даже более ценен, чем 100.

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

• О (обязательный): Обязательный верхний (или нижний) предел значения величины;.

• Ж (желаемый): Желаемое значение;.

• Н (наилучший): Наилучшее значение.

Каждое из этих значений может храниться в собственном атрибуте требования или же они могут быть описаны непосредственно в тексте требования, например, в такой форме: «Система должна поддерживать функционирование [О:50, Ж:100, Н:200] одновременно работающих пользователей».

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

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

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

Функция (b) иллюстрирует бинарный случай - либо определенная производительность (в 100 единиц) достигается, либо нет. При этом даже 200 одновременно работающих пользователей не приносят никакой дополнительной пользы заказчику.

Функция (с) отражает случай, когда значение показателя должно быть минимизировано (например, вес устройства), но при этом определен и максимально допустимый вес - 50 кг. Функция (d) - это когда значение показателя должно быть оптимизировано (например, обороты двигателя).

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

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

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

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

4.8 Язык требований.

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

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

В частности, этот принцип использует Telelogic Assessment Management, базирующийся на Doors.

даже предписывают использование отличающихся ключевых слов для характеристики приоритета требований, например - «должно» (must), «рекомендуется» (should) и «возможно» (may).

Следует заметить, что язык, используемый для написания требований, в значительной степени зависит от «уровня» документа с требованиями, т.е. существует принципиальное отличие между пользовательскими требованиями, которые относятся к проблемной области, и системными требованиями, которые относятся к области решений (см. раздел 1.7).

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

При этом в тексте требования должен указываться типа пользователя.

Типичное требование, описывающее возможность (потребность), выглядит следующим образом:.

должен иметь возможность.

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

должен иметь возможность с от , находясь в.

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

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

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

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

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

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

Требование типа ограничение обычно выражается в следующей форме:.

не должен попадать под действиезаконодательство>.

Пример из реальной жизни:.

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

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

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

должна не менее чем функционируя в.

Или в реалиях:.

Телекоммуникационная система должна обеспечивать телефонную связь не менее чем с 10 абонентами,.

функционируя в условиях отсутствия внешнего источника электропитания.

Приведем другой пример, описывающий периодическое ограничение:.

должна каждые.

На языке инструкции это выглядит:.

Кофе-машина должна производить горячий напиток каждые 10 секунд.

Мы продолжим обсуждение этой темы в последующих разделах.