Контролируемый словарь
Шаблоны (также известны как контролируемый естественный язык) — это построенные по определенным правилам структуры предложений. Используя шаблоны для разработки требований, аналитики сразу же и впечатляюще способны улучшить качество формулировок требований.
Пример шаблона
Менеджер по продажам хочет, чтобы система отправляла электронные письма тысячам клиентов. И формулирует следующие требования:
«Я хочу следить за ходом каждой рассылки, пока она идет». «Должны отображаться сообщения о статусе рассылки».
Опытный аналитик интуитивно знает, что здесь отсутствует важная информация. Например:
- что вызывает отправку сообщения о состоянии?
- кто или что посылает сообщение?
- что в сообщении?
Откуда взялась эта интуиция? Как аналитик определил, что чего-то не хватает, посмотрев на то, что было? В таких ситуациях хорошие аналитики, иногда неосознанно, просто обращаются к своей мысленной библиотеке шаблонов требований, выбирают подходящего кандидата и выполняют быстрый анализ пробелов в атрибутах, которые им нужны для определенного типа требований. Например, заявление менеджера по продажам звучит как требование, обусловленное событием, и следующий шаблон является хорошим кандидатом для использования:
{Когда} 〈событие〉 〈субъект〉 {должен} 〈действие〉 〈объект действия〉 〈дальнейшее уточнение действия〉
Задав уточняющие вопросы, аналитик может переформулировать требование в соответствии с этим шаблоном:
{Когда} 〈рассылка завершена〉 〈почтовая программа〉 {должен} 〈отображать〉 〈сообщение о статусе рассылки〉 〈содержащее: дату и время рассылки, статус и процент успешных доставок〉
Таким образом, знание языка шаблонов может помочь найти то, чего не хватает, изучая то, что есть.
Как онтологии улучшают качество
Если у вас есть шаблонное выражение, вы решили только часть проблемы со спецификацией. Следование шаблону только очищает синтаксис и помогает найти недостающую информацию. А как же смысл того, что вы написали? Является ли он правильным, полным и недвусмысленным в вашей прикладной области? Именно здесь онтологии выводят спецификацию требований на новый уровень.
Онтология — это, по существу, предметно-ориентированный словарь «сущностей» и их отношений. В приведенном выше примере «сущность», которая отправляет сообщение, всегда будет называться «почтовой программой». Онтология также зафиксирует тот факт, что почтовая программа способна «отправить сообщение о статусе рассылки». По мере того, как мы обнаруживаем, что еще может делать почтовая программа, мы добавляем в онтологию новые 〈действия〉.
Имея онтологию, мы можем дисциплинировать спецификацию требований. Когда онтология выступает в роли оракула, спецификатор ограничен документированием только тех фактов, которые онтология знает как истинные. Например, мы не можем по ошибке указать, что почтовая программа отправляет счета.
Таким образом, интеграция онтологии предметной области с языком шаблонов значительно повышает качество спецификации — обычно в первом выпуске — тем самым устраняя дорогостоящие доработки. Построение онтологии — нетривиальная задача, но она того стоит. Стоимость дефектных требований может быть катастрофической, особенно если они не обнаруживаются до тех пор, пока система не начнет использоваться. Неудачи на сотни миллионов долларов — обычное дело.
Важно
Шаблон обеспечивает структуру (синтаксис), а онтология обеспечивает смысл (семантика)
Онтология требований
Разработаем онтологию, с помощью которой мы сможем специфицировать требования по шаблону. Один из способов определить объем и содержание онтологии – это набросать список вопросов, на которые должна ответить база знаний, основанная на онтологии. Эти вопросы являются формальными и не должны быть исчерпывающими. В рассматриваемой области, список вопросов может быть следующим:
- Какие шаблоны используются для спецификации требований?
- Какие действия могут совершать акторы?
- Над какими объектами совершаются действия?
- Какие требования сформулированы для актора Х?
- Какие требования сформулированы для объекта Y?
Теперь перечислим основные понятия, определим классы и иерархии классов, свойства и отношения, создадим определения для терминов: Требование, Актор, Действие, Объект действия, Требование Универсальное, Требование Событийное, Требование с Пред/Пост Условием, Требование Состояние.
В нашей онтологии мы выделили четыре шаблона, с помощью которых могут быть специфицированы требования:
- Шаблон "Универсальный": 〈Актор〉 {должен иметь возможность} 〈Действие〉 {для} 〈Объект действия〉
- Шаблон "Состояние": {В состоянии} 〈Состояние〉 〈Актор〉 {должен} 〈Действие〉 〈объект действия〉 〈Уточнение действия〉
- Шаблон "Пред/Пост-условие": {Если} 〈Предусловие〉, {то} 〈Актор〉 〈Действие〉 〈Объект действия〉 {таким образом, чтобы} 〈Постусловие〉
- Шаблон "Событийный": {Когда} 〈Событие〉 {и} 〈Предусловие〉, 〈Актор〉 {должен} 〈Действие〉 〈Объект действия〉
Для каждого из шаблонов создан отдельный класс и определены правила имяобразований.
Преимущества требований, основанных на онтологии
Применение онтологии к формулировкам требований значительно повышает их точность и согласованность. Кроме того, учитывая, что атрибуты, полученные из онтологии, применяются к именованным заполнителям в шаблонах требований (например, 〈Актор〉, 〈Событие〉...), можно проанализировать спецификацию с помощью программного инструмента. Таким образом, спецификация перестает быть набором слов, которые может интерпретировать только человек - она становится машиночитаемой.
Применение предопределенных атрибутов также устраняет двусмысленность: конкретное событие всегда описывается одним и тем же текстом; объект всегда называется одним и тем же именем.
Онтология также позволяет автоматическим инструментам оценивать точность требований. Например, инструмент может обнаружить действие, которое было неправильно назначено конкретному актору.