Таким образом, процесс создания требований с помощью шаблонов может быть разбит на два этапа:.
• выбор наиболее подходящего шаблона из общего набора шаблонов;.
• подстановка конкретных данных для заполнения пустующих полей в шаблоне.
Такой подход дает возможность разделить шаблон и данные, подставляемые в него. Тогда любое требование будет просто содержать ссылку на шаблон, а данные могут фиксироваться отдельно - как атрибуты этого требования.
На рис. 4.3 приведен пример, иллюстрирующий вышесказанное.
Такой «шаблонный» подход дает возможность сгенерировать текстовое представление требования в любой нужный момент. Использование выделенных шаблонов имеет.
7.
следующие преимущества :.
• Возможность глобального изменения стиля: для изменения формулировки определенных требований необходимо внести изменение только в один или несколько конкретных шаблонов, которые задействованы в этой схеме.
• Возможность более легкой обработки информации: например, выделение всех полей, относящихся к , в отдельный атрибут требований позволяет более удобно фильтровать и сортировать требования, исходя из конкретных признаков условия эксплуатации.
• Возможность защиты конфиденциальной информации: в том случае, когда требования содержат конфиденциальную или секретную информацию, шаблоны могут быть использованы для защиты именно той части текста требования, доступ к которой должен быть защищен.
Последний пункт, несомненно, нуждается в некотором уточнении.
В оборонных и некоторых коммерческих проектах необходимо ограничивать доступ, но не ко всей информации, а только к некоторой ее части. Очень часто текст одного требования содержит информацию, относящуюся к различным уровням секретности.
Например, совершенно очевидно (не секретно), что современный военный корабль будет оснащен ракетами, которые он будет запускать, однако следующая информация о производительности может носить закрытый характер: возможное количество запусков в единицу времени, радиус поражения и т. д.
Вместо того, чтобы ограничивать доступ к целому требованию только из-за того, что некоторая его часть является конфиденциальной, данный подход дает возможность разрешить просматривать всё требование, но без доступа к конфиденциальной информации, содержащейся в некоторых его атрибутах. В действительности, при использовании такого подхода различные участники проекта (с разным уровнем доступа) могут видеть разные наборы атрибутов.
Одним из самых сложных с точки зрения формулирования и, к сожалению, одним из наиболее распространенных типов требований являются ограничения. Так вот как раз для ограничений метод шаблонов существенным образом облегчает задачу формулировки требований.
Авторы предлагают следующий подход для формулирования ограничений:.
1.
В первую очередь, соберите все возможные требования.
2.
Подготовьте список ограничений различных типов, которые могут встретиться при работе над вашим проектом.
Если этот список основан на предыдущем опыте выполнения аналогичного проекта, то, в этом случае, у вас уже есть полный набор шаблонов с ограничениями, который вы можете использовать для описания ограничений текущего проекта. В противном случае, вам придется разрабатывать новые шаблоны.
прим. переводчика: Необходимо также отметить один предполагаемый недостаток метода - для русского языка применение данного метода может осложняться необходимостью согласования падежей.
3.
Применительно к каждому требованию рассмотрите полный перечень возможных ограничений из вашего списка и определите, какие именно из них должны быть применимы (зафиксированы) для этого требования.
Для выполнения этой процедуры очень удобно использовать таблицу. Столбцы будут соответствовать различным типам ограничений, а строки - ограничениям.
Если для требования необходимо добавить ограничение определенного типа, то в соответствующей ячейке необходимо сформулировать это ограничение; если же необходимости в ограничении вообще нет, то в соответствующей ячейке нужно поставить «нет» (или N/A = not available).
4.
Для каждого ограничения необходимо выбрать наиболее подходящий для него шаблон и сформулировать требование с его помощью.
5.
Процесс заканчивается в тот момент, когда все ячейки таблицы заполнены.
Использование такого подхода позволяет ответить на два часто задаваемых вопроса:.
• Как формулировать требование, в котором должно быть ограничение?.
(Ответ: использовать шаблоны).
• Как убедиться в том, что все ограничения учтены?.
(Ответ: использовать таблицу для анализа покрытия требований с ограничениями).
В таблице 4.4 показан пример набора шаблонов для требований с ограничениями.
Обратите внимание на тот факт, что для одного типа ограничений могут использоваться различные шаблоны, а так же на то, что ограничения могут иметь сложную классификацию. В приведенных примерах только текст, выделенный жирным шрифтом, относится непосредственно к самому ограничению.
Таблица 4.4 Примеры шаблонов требований с ограничением
Тип ограничения | Шаблон |
П роизводительность/возможность | должна не менее чем раз в |
Производительность/возможность | должна типа в течение |
Производительность/мощность | должна не менее чем |
Производительность/своевременность | должна в течение с момента |
Производительность/периодичность | должна не менее чем в течение |
Устойчивость/периодичность | должна с каждые |
Окружение/работоспособность | должна функционируя в |
4.10 Детализация требований.
Использование шаблонов для «конструирования» требований позволяет практиковать следующее - некоторые ограничения или показатели производительности могут формулироваться и существовать как отдельные подпункты (подклассы) соответствующих функциональных требований.
Такой подход позволяет выделять эти подклассы в виде отдельных требований и устанавливать для них связи с соответствующими функциональными требованиям.
Вот тут то, как раз и возникает вопрос о степени (глубине) детализации информации. До какой же степени мы собираемся «расщеплять атом» при разработке требований?.
На этот вопрос можно ответить следующим образом: требование может дробиться на подпункты до тех пор, пока средство поддержки работы с требованиями (Requirements Management tool) дает вам возможность видеть каждое требование в нужном контексте.
На рис. 4.4 представлен способ разделения требования, при котором подпункты становятся дочерними требованиями основного требования, образуя, таким образом, определенную иерархию. При этом главное требование остается пригодным для чтения и понимания само по себе, в то время как дочерние требования могут рассматриваться только в контексте «родительского» требования, хотя в отношении трассировки и связей они могут существовать вполне автономно.
Рис. 4.4 Показатели производительности и ограничения, как подпункты.
Телекоммуникационная система должна поддерживать телефонную связь.
-функционируя в условиях отсутствия внешнего источника электроэнергии.
Другими словами, вы можете работать с дочерним требованием как с вполне законченным элементом, пригодным для трассировки, но цитировать (увязывать) дочернее требование лучше все-таки вместе с текстом родительского требования.
Если вновь обратиться к примеру на рис. 4.4, выделив курсивом текст родительского требования в тексте дочерних требований, то имеется в виду следующее:.
• Телекоммуникационная система должна обеспечивать телефонную связь.
• Телекоммуникационная система должна обеспечивать телефонную связь.
не менее чем с 10 абонентами.
• Телекоммуникационная система должна обеспечивать телефонную связь,.
функционируя в условиях отсутствия внешнего источника электропитания.
Существуют различные способы организации иерархии таких подклассов. Предположим, что необходимо описать несколько разных возможностей, которые должны быть доступны «в условиях отсутствия внешнего источника электроэнергии».
Вариант организации требований представлен на рис. 4.5.
Функционируя а усгоииях OTcyic-иия внешнего источника электроэнергии
Рис. 4.5 Альтернативное представление подпунктов.
- те леком му ни ка ци очная система должна поддерживать телефонную связь.
I- не менее чем с 10 абонентами.
- телекоммуникационная система должна поддерживать радиосвязь.
I- не менее чем с 15 води-^лями скорой помощи.
Для этого примера взаимосвязь между требованиями будет выглядеть иначе:.
• В условиях отсутствия внешнего источника электроэнергии телекоммуникационная система должна поддерживать телефонную связь.
• В условиях отсутствия внешнего источника электроэнергии телекоммуникационная система должна поддерживать телефонную связь, не менее чем с 10 абонентами.
• В условиях отсутствия внешнего источника электроэнергии телекоммуникационная система должна поддерживать радиосвязь.
• В условиях отсутствия внешнего источника электроэнергии телекоммуникационная система должна поддерживать радиосвязь, не менее чем с 15 водителями скорой помощи.
Другими словами суть такого подхода состоит в том, что при построении иерархии требований (их детализации) родительское требование должно формулироваться таким образом, чтобы обеспечивать полный смысловой контекст для каждого дочернего требования, включая и возможную последующую детализацию дочерних требований на более мелкие блоки информации.