Embed Size (px)
Citation preview
EARS: The Easy Approach to Requirements
Syntax
Павлов АндрейT-Systems CIS, Санкт-Петербург
About me
• Ex-Developer
• Выпускник СПБ НИУ ИТМО
• Senior QA @ T-Systems CIS
linkedin.com/in/qapavlov
Как мы дошли до EARS
• Писали на естественном языке
• Новый проект
• Почему бы не попробовать?
• А давайте теперь то же самое для большого проекта?
EARS: Easy Approach to Requirements Syntax
Введение
Высокоуровневые требования к системе обычно формулируются на естественном языке. Свободные формулировки на естественном языке могут вызывать различные проблемы интерпретации текста и, как следствие, влиять на качество требований.
Что такое требования?Требование - описание одного из следующих пунктов:
1. Что система должна делать2. Известное ограничение на проектные ресурсы3. Определение, как хорошо система должна делать то, что она делает
Первое определение относится к Функциональным ТребованиямВторое и третье определения относятся к Нефункциональным Требованиям
Больший фокус в докладе приходится на улучшении требований, определенных пунктами 1 и 2.
Проблемы с требованиями1. Программное обеспечение должно поддерживать датчик уровня воды.• Что значит слово “поддерживать”?
2. Программное обеспечение словаря должно вывести на экран приблизительно пять альтернатив для требуемого слова.• “Приблизительно пять” – это сколько? Три? Четыре? Шесть? Десять? Больше?• При каких условиях они должны быть выведены на экран?
3. Программное обеспечение должно мигнуть LED светодиодом• Программное обеспечение мигает LED в любом случае? Или есть триггер, который инициирует это мигание?
4. Если загрузочный диск будет обнаружен в системе, то программное обеспечение должно загрузиться с него.• А что, если загрузочный диск не присутствует? Пример неполной логики.
Преодоление проблем с требованиями
Основными вариантами решения озвученных выше проблем являются:
• Обучение• Использование непротиворечивого синтаксиса для описания требований• Проверка требования по критериям “совершенства”• Использование ограниченного естественного языка (например, Planguage)• Создание требований с использованием EARS
Использование непротиворечивого синтаксиса для описания требований
[Trigger] [Precondition] Actor Action [Object]
Пример:Когда Заказ доставлен, и Статус не “Prepaid”, система должна создать Инвойс.• Триггер: Когда Заказ доставлен• Предварительное условие: Статус не “Prepaid”• Кто производит действие: система• Действие: создать• Объект: Инвойс
Planguage: ограниченный естественный язык
• Он был разработан Томом Джилбом в 1988 и подробно рассмотрен в его книге Competitive EngineeringНазван по комбинации слов Planning and Language• Представляет собой неофициальный, но структурированный, keyword-driven язык планирования• Может использоваться для создания всех типов требований
Ключевые слова Planguage для описания любого требования
Name – короткое описательное имя
Requirement - текст, который определяет требование
Rationale – описание, оправдывающее требование
Priority - приоритет требования относительно других
Priority Reason - причина для присвоенного приоритетного уровня
Status - текущее состояние требования
Contract – с кем можно связаться с вопросами о требовании
Source – источник требования
Пример PlanguageName: Create_Invoice
Requirement: Когда Заказ доставлен, и Статус не “Prepaid”, система должна создать Инвойс.
Rationale: Автоматизация задачи уменьшает количество ошибок, снижая трудозатраты.
Priority: высоко.
Priority Reason: Если требование не реализовано, будет необходимо вручную реализовать данный процесс, что отразится на ROI и потребует $400 тысяч в год. (#ссылка на документ финансового анализа)
Status: CommittedContract: Василий ВасинSource: Совет директоровCreated by: Андрей ПавловVersion: 1.1, Modified Date: 12-01-2016
Создание требований с использованием EARS
EARS: Easy Approach to Requirements Syntax
Эффективный метод выражения требований
Дифференцируется между пятью типами (или образцами) требований:
• Ubiquitous (повсеместный, всегда происходящий)• Event-driven (управляемый событиями)• Unwanted behaviors (нежелательное поведение)• State-driven (управляемый состоянием)• Optional features (дополнительные функции)
EARS background• Первое использование было произведено группой разработчиков Роллс-ройса, работающей над системами управления авиационного двигателя
• Программное обеспечение было safety critical, содержавшее в себе тысячи компонентов и включало до двадцати различных исполнителей
• Роллс-ройс идентифицировал 8 основных проблем с существующими требованиями естественного языка:
НеоднозначностьДублированиеМногословностьНеопределенностьСложностьВозможность упущения чего-то (Omission)Несоответствие реализацииНетестируемость
• Перезапись требований, используя EARS “… демонстрировало значительное сокращение всех восьми проблемных типов …” (из EARS Alistair Mavin et al, 17th IEEE RE 09, page 321)
Идентификация повсеместных (Ubiquitous) требований
Повсеместные требования:
• Имеют статус фундаментального свойства системы• Не требует триггера для выполнения• Универсальны (существуют в любом случае)
Требования, которые не являются повсеместными, происходят не в любом случае. Они:
• Требуют события или триггера, чтобы выполняться, или• Обозначают свойство системы, или• Обозначают дополнительную функцию
Большинство требований не повсеместно!
Практика выявления повсеместных требований
Инсталлятор приложения должен поддерживать немецкий язык Да! Это фундаментальное свойство системы.
Приложение должно показывать количество участников звонкаНет! Должно быть какое-то событие, которое определяет, когда количество должно быть показано.
Приложение должно отправлять отчет об ошибкеНет! Отчет об ошибке должен быть отправлен только если мы с этой ошибкой столкнулись.
Практика выявления повсеместных требований
Приложение должно распространяться на CD-ROM и DVD дискахДа! Это фундаментальное свойство системы.
Программное обеспечение должно предотвращать неавторизированный доступ к конфиденциальным данным.Да! Это снова фундаментальное свойство системы.
Приложение должно сигнализировать о низком заряде батареи Нет! Нужно указание состояния, когда предупреждение должно быть показано.
Паттерны EARS
Pattern Name Pattern
Ubiquitous The <system name> shall <system response>
Event-Driven WHEN <trigger> <optional precondition> the <system name> shall <system response>
Unwanted Behavior IF <unwanted condition or event>, THEN the <system name> shall <system response>
State-Driven WHILE <system state>, the <system name> shall <system response>
Optional Feature WHERE <feature is included>, the <system name> shall <system response>
Complex (combinations of the above patterns)
Использование EARS для переписывания существующих требований
Оригинальное требование:Программное обеспечение должно быть доступным на немецком языке.
Переписанное c использованием EARS:Программное обеспечение должно быть доступным на немецком языке.
Нет изменений. Почему?
Какой использован паттерн EARS?
Повсеместный(Ubiquitous)
Использование EARS для переписывания существующих требований
Оригинальное требование:Программное обеспечение должно показать количество участников
Переписанное c использованием EARS:Когда пользователь выберет счетчик участников из меню, программное обеспечение должно показать количество участников в UI.
Какой использован паттерн EARS?
Управляемый событиями (Event Driven)
Использование EARS для переписывания существующих требований
Оригинальное требование:Программное обеспечение должно показывать свойства опции.
Переписанное c использованием EARS:В то время когда мышь наведена на опцию, программное обеспечение должно показать свойство этой опции.
Какой использован паттерн EARS?
Управляемый событиями (Event Driven)
Использование EARS для переписывания существующих требований
Оригинальное требование:Программное обеспечение должно загрузить бонусные приложения бесплатно
Переписанное c использованием EARS:Где бонусные приложения доступны, программное обеспечение должно позволить пользователю загружать бонусные приложения бесплатно в течение трехдневного триального периода
Какой использован паттерн EARS?
Дополнительные функции (Optional feature)
Что дало нам использование EARS1. EARS помог нам лучше писать требования за счет улучшения
структурирования, с помощью повышения внимания на использовании ключевых слов (When, If-Then, While, Where и их комбинации)
2. EARS помог нам определить, какие требования действительно повсеместны. Некоторые требования, записанные, будто они повсеместны, на самом деле таковыми не являлись.
3. EARS удобен и для разработчиков и для тестировщиков в понимании требований. Он исключает двусмысленность, улучшает ясность и должным образом определяет основные условия или триггеры.
Итог
EARS - это простой и мощный метод получения функциональных требований, который вы легко можете применить в своем проекте, вне зависимости, будете ли вы писать новые требования или переписывать существующие, используя шаблоны EARS.
До использования EARS84
С использованием EARS16
Количество вопросов в Confluence
До использования EARS С использованием EARS0
102030405060708090
Количество багов, закрытых как By Design
Вопросы
linkedin.com/in/qapavlov
