Доклад Андрея Павлова на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com

1. EARS:
The Easy Approach to
Requirements Syntax
Павлов Андрей
T-Systems CIS, Санкт-Петербург

2. About me
• Ex-Developer
• Выпускник СПБ НИУ ИТМО
• Senior QA @ T-Systems CIS
linkedin.com/in/qapavlov
ru.apavlov@gmail.com

3. Как мы дошли до EARS
• Писали на естественном языке
• Новый проект
• Почему бы не попробовать?
• А давайте теперь то же самое для большого проекта?
EARS: Easy Approach to Requirements Syntax

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

5. Что такое требования?
Требование - описание одного из следующих пунктов:
1. Что система должна делать
2. Известное ограничение на проектные ресурсы
3. Определение, как хорошо система должна делать то, что она делает
Первое определение относится к Функциональным Требованиям
Второе и третье определения относятся к Нефункциональным Требованиям
Больший фокус в докладе приходится на улучшении требований,
определенных пунктами 1 и 2.

6. Проблемы с требованиями
1. Программное обеспечение должно поддерживать датчик уровня воды.
• Что значит слово “поддерживать”?
2. Программное обеспечение словаря должно вывести на экран приблизительно
пять альтернатив для требуемого слова.
• “Приблизительно пять” – это сколько? Три? Четыре? Шесть? Десять? Больше?
• При каких условиях они должны быть выведены на экран?
3. Программное обеспечение должно мигнуть LED светодиодом
• Программное обеспечение мигает LED в любом случае? Или есть триггер,
который инициирует это мигание?
4. Если загрузочный диск будет обнаружен в системе, то программное
обеспечение должно загрузиться с него.
• А что, если загрузочный диск не присутствует? Пример неполной логики.

7. Преодоление проблем с требованиями
Основными вариантами решения озвученных выше проблем являются:
• Обучение
• Использование непротиворечивого синтаксиса для описания требований
• Проверка требования по критериям “совершенства”
• Использование ограниченного естественного языка (например,
Planguage)
• Создание требований с использованием EARS

8. Использование непротиворечивого
синтаксиса для описания требований
[Trigger] [Precondition] Actor Action [Object]
Пример:
Когда Заказ доставлен, и Статус не “Prepaid”, система должна создать Инвойс.
• Триггер: Когда Заказ доставлен
• Предварительное условие: Статус не “Prepaid”
• Кто производит действие: система
• Действие: создать
• Объект: Инвойс

9. Planguage: ограниченный
естественный язык
• Он был разработан Томом Джилбом в 1988 и подробно рассмотрен в его
книге Competitive Engineering
Назван по комбинации слов Planning and Language
• Представляет собой неофициальный, но структурированный, keyword-driven
язык планирования
• Может использоваться для создания всех типов требований

10. Ключевые слова Planguage для описания
любого требования
Name – короткое описательное имя
Requirement - текст, который определяет требование
Rationale – описание, оправдывающее требование
Priority - приоритет требования относительно других
Priority Reason - причина для присвоенного приоритетного уровня
Status - текущее состояние требования
Contract – с кем можно связаться с вопросами о требовании
Source – источник требования

11. Пример Planguage
Name: Create_Invoice
Requirement: Когда Заказ доставлен, и Статус не “Prepaid”, система должна
создать Инвойс.
Rationale: Автоматизация задачи уменьшает количество ошибок, снижая
трудозатраты.
Priority: высоко.
Priority Reason: Если требование не реализовано, будет необходимо вручную
реализовать данный процесс, что отразится на ROI и потребует $400 тысяч в
год. (#ссылка на документ финансового анализа)
Status: Committed
Contract: Василий Васин
Source: Совет директоров
Created by: Андрей Павлов
Version: 1.1, Modified Date: 12-01-2016

12. Создание требований с использованием
EARS
EARS: Easy Approach to Requirements Syntax
Эффективный метод выражения требований
Дифференцируется между пятью типами (или образцами) требований:
• Ubiquitous (повсеместный, всегда происходящий)
• Event-driven (управляемый событиями)
• Unwanted behaviors (нежелательное поведение)
• State-driven (управляемый состоянием)
• Optional features (дополнительные функции)

13. EARS background
• Первое использование было произведено группой разработчиков Роллс-ройса,
работающей над системами управления авиационного двигателя
• Программное обеспечение было safety critical, содержавшее в себе тысячи
компонентов и включало до двадцати различных исполнителей
• Роллс-ройс идентифицировал 8 основных проблем с существующими
требованиями естественного языка:
Неоднозначность
Дублирование
Многословность
Неопределенность
Сложность
Возможность упущения чего-то (Omission)
Несоответствие реализации
Нетестируемость
• Перезапись требований, используя EARS
“… демонстрировало
значительное сокращение всех восьми проблемных типов …”
(из EARS Alistair Mavin et al, 17th IEEE RE 09, page 321)

14. Идентификация повсеместных (Ubiquitous)
требований
Повсеместные требования:
• Имеют статус фундаментального свойства системы
• Не требует триггера для выполнения
• Универсальны (существуют в любом случае)
Требования, которые не являются повсеместными,
происходят не в любом случае. Они:
• Требуют события или триггера, чтобы выполняться, или
• Обозначают свойство системы, или
• Обозначают дополнительную функцию
Большинство требований не повсеместно!

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

16. Практика выявления повсеместных
требований
Приложение должно распространяться на CD-ROM и DVD дисках
Да! Это фундаментальное свойство системы.
Программное обеспечение должно предотвращать
неавторизированный доступ к конфиденциальным данным.
Да! Это снова фундаментальное свойство системы.
Приложение должно сигнализировать о низком заряде батареи
Нет! Нужно указание состояния, когда предупреждение должно
быть показано.

17. Паттерны 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)

18. Использование EARS для переписывания
существующих требований
Оригинальное требование:
Программное обеспечение должно быть доступным на немецком языке.
Переписанное c использованием EARS:
Программное обеспечение должно быть доступным на немецком языке.
Нет изменений. Почему?
Какой использован паттерн EARS?
Повсеместный(Ubiquitous)

19. Использование EARS для переписывания
существующих требований
Оригинальное требование:
Программное обеспечение должно показать количество участников
Переписанное c использованием EARS:
Когда пользователь выберет счетчик участников из меню, программное
обеспечение должно показать количество участников в UI.
Какой использован паттерн EARS?
Управляемый событиями (Event Driven)

20. Использование EARS для переписывания
существующих требований
Оригинальное требование:
Программное обеспечение должно показывать свойства опции.
Переписанное c использованием EARS:
В то время когда мышь наведена на опцию, программное обеспечение
должно показать свойство этой опции.
Какой использован паттерн EARS?
Управляемый событиями (Event Driven)

21. Использование EARS для переписывания
существующих требований
Оригинальное требование:
Программное обеспечение должно загрузить бонусные приложения бесплатно
Переписанное c использованием EARS:
Где бонусные приложения доступны, программное обеспечение должно
позволить пользователю загружать бонусные приложения бесплатно в течение
трехдневного триального периода
Какой использован паттерн EARS?
Дополнительные функции (Optional feature)

22. Что дало нам использование EARS
1. EARS помог нам лучше писать требования за счет улучшения
структурирования, с помощью повышения внимания на использовании
ключевых слов (When, If-Then, While, Where и их комбинации)
2. EARS помог нам определить, какие требования действительно повсеместны.
Некоторые требования, записанные, будто они повсеместны, на самом деле
таковыми не являлись.
3. EARS удобен и для разработчиков и для тестировщиков в понимании
требований. Он исключает двусмысленность, улучшает ясность и должным
образом определяет основные условия или триггеры.

23. Итог
EARS - это простой и мощный метод получения функциональных требований,
который вы легко можете применить в своем проекте, вне зависимости, будете
ли вы писать новые требования или переписывать существующие, используя
шаблоны EARS.
До использования
EARS
84
С использованием EARS
16
Количество вопросов в Confluence
0
10
20
30
40
50
60
70
80
90
До использования EARS С использованием EARS
Количество багов, закрытых как By Design

24. Вопросы
linkedin.com/in/qapavlov
ru.apavlov@gmail.com