SlideShare a Scribd company logo

EARS: The Easy Approach to Requirements Syntax

SQALab
SQALab

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

1 of 24
Download to read offline
EARS:
The Easy Approach to
Requirements Syntax
Павлов Андрей
T-Systems CIS, Санкт-Петербург
About me
• Ex-Developer
• Выпускник СПБ НИУ ИТМО
• Senior QA @ T-Systems CIS
linkedin.com/in/qapavlov
ru.apavlov@gmail.com
Как мы дошли до EARS
• Писали на естественном языке
• Новый проект
• Почему бы не попробовать?
• А давайте теперь то же самое для большого проекта?
EARS: Easy Approach to Requirements Syntax
Введение
Высокоуровневые требования к системе обычно формулируются на естественном
языке.
Свободные формулировки на естественном языке могут вызывать различные
проблемы интерпретации текста и, как следствие, влиять на качество требований.
Что такое требования?
Требование - описание одного из следующих пунктов:
1. Что система должна делать
2. Известное ограничение на проектные ресурсы
3. Определение, как хорошо система должна делать то, что она делает
Первое определение относится к Функциональным Требованиям
Второе и третье определения относятся к Нефункциональным Требованиям
Больший фокус в докладе приходится на улучшении требований,
определенных пунктами 1 и 2.
Проблемы с требованиями
1. Программное обеспечение должно поддерживать датчик уровня воды.
• Что значит слово “поддерживать”?
2. Программное обеспечение словаря должно вывести на экран приблизительно
пять альтернатив для требуемого слова.
• “Приблизительно пять” – это сколько? Три? Четыре? Шесть? Десять? Больше?
• При каких условиях они должны быть выведены на экран?
3. Программное обеспечение должно мигнуть LED светодиодом
• Программное обеспечение мигает LED в любом случае? Или есть триггер,
который инициирует это мигание?
4. Если загрузочный диск будет обнаружен в системе, то программное
обеспечение должно загрузиться с него.
• А что, если загрузочный диск не присутствует? Пример неполной логики.
Ad

Recommended

Постоянные переключения контекста в жизни аналитика
Постоянные переключения контекста в жизни аналитикаПостоянные переключения контекста в жизни аналитика
Постоянные переключения контекста в жизни аналитикаSQALab
 
Gap-анализ требований к внедряемым системам
Gap-анализ требований к внедряемым системамGap-анализ требований к внедряемым системам
Gap-анализ требований к внедряемым системамSPbCoA
 
Прокачиваем информационные системы с помощью data science
Прокачиваем информационные системы с помощью data scienceПрокачиваем информационные системы с помощью data science
Прокачиваем информационные системы с помощью data scienceSQALab
 
Человек со стокгольмским синдромом
Человек со стокгольмским синдромомЧеловек со стокгольмским синдромом
Человек со стокгольмским синдромомSQALab
 
Ментальная математика для инженеров
Ментальная математика для инженеровМентальная математика для инженеров
Ментальная математика для инженеровSQALab
 
Как не потерять Продукт на завершающем этапе.
Как не потерять Продукт на завершающем этапе.Как не потерять Продукт на завершающем этапе.
Как не потерять Продукт на завершающем этапе.SQALab
 
Управленческие инструменты: отслеживание состояния людей
Управленческие инструменты: отслеживание состояния людейУправленческие инструменты: отслеживание состояния людей
Управленческие инструменты: отслеживание состояния людейSQALab
 
Agile methods and safety critical software - Peter Gardner
Agile methods and safety critical software - Peter GardnerAgile methods and safety critical software - Peter Gardner
Agile methods and safety critical software - Peter GardnerAdaCore
 

More Related Content

Viewers also liked

Управление Рисками в бизнес-анализе
Управление Рисками в бизнес-анализеУправление Рисками в бизнес-анализе
Управление Рисками в бизнес-анализеSQALab
 
СПб СОА Анна Абрамова "Знакомство с Archimate"
СПб СОА Анна Абрамова "Знакомство с Archimate"СПб СОА Анна Абрамова "Знакомство с Archimate"
СПб СОА Анна Абрамова "Знакомство с Archimate"SPbCoA
 
Введение в Управление проектами
Введение в Управление проектамиВведение в Управление проектами
Введение в Управление проектамиMakemote
 
Птички и пчелки. Как документировать сложное просто
Птички и пчелки. Как документировать сложное простоПтички и пчелки. Как документировать сложное просто
Птички и пчелки. Как документировать сложное простоSQALab
 
Жаргон как средство повышения эффективности работы над проектом
Жаргон как средство повышения эффективности работы над проектомЖаргон как средство повышения эффективности работы над проектом
Жаргон как средство повышения эффективности работы над проектомSQALab
 
управление заинтересованными сторонами
управление заинтересованными сторонамиуправление заинтересованными сторонами
управление заинтересованными сторонамиVyacheslav Benedichuk
 
Всегда ли рыба гниет с головы, или развитие управленческих компетенций
Всегда ли рыба гниет с головы, или развитие управленческих компетенцийВсегда ли рыба гниет с головы, или развитие управленческих компетенций
Всегда ли рыба гниет с головы, или развитие управленческих компетенцийSQALab
 
Варианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовВарианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовSQALab
 
Подходы к спецификации изменений
Подходы к спецификации измененийПодходы к спецификации изменений
Подходы к спецификации измененийSQALab
 
Customer Journey Mapping для бизнес-аналитиков и не только
Customer Journey Mapping для бизнес-аналитиков и не толькоCustomer Journey Mapping для бизнес-аналитиков и не только
Customer Journey Mapping для бизнес-аналитиков и не толькоSQALab
 
To requirements and beyond...
To requirements and beyond...To requirements and beyond...
To requirements and beyond...SQALab
 
Коммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономииКоммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономииSQALab
 
Моделирование бизнес-процессов: методы и инструменты
Моделирование бизнес-процессов: методы и инструментыМоделирование бизнес-процессов: методы и инструменты
Моделирование бизнес-процессов: методы и инструментыSQALab
 
Подбор кандидатов на позицию бизнес аналитика
Подбор кандидатов на позицию бизнес аналитикаПодбор кандидатов на позицию бизнес аналитика
Подбор кандидатов на позицию бизнес аналитикаJulia Shamrey
 
Заинтересованные лица: классификация, выявление, анализ, техники
Заинтересованные лица: классификация, выявление, анализ, техникиЗаинтересованные лица: классификация, выявление, анализ, техники
Заинтересованные лица: классификация, выявление, анализ, техникиSQALab
 

Viewers also liked (16)

Управление Рисками в бизнес-анализе
Управление Рисками в бизнес-анализеУправление Рисками в бизнес-анализе
Управление Рисками в бизнес-анализе
 
СПб СОА Анна Абрамова "Знакомство с Archimate"
СПб СОА Анна Абрамова "Знакомство с Archimate"СПб СОА Анна Абрамова "Знакомство с Archimate"
СПб СОА Анна Абрамова "Знакомство с Archimate"
 
Введение в Управление проектами
Введение в Управление проектамиВведение в Управление проектами
Введение в Управление проектами
 
Птички и пчелки. Как документировать сложное просто
Птички и пчелки. Как документировать сложное простоПтички и пчелки. Как документировать сложное просто
Птички и пчелки. Как документировать сложное просто
 
Жаргон как средство повышения эффективности работы над проектом
Жаргон как средство повышения эффективности работы над проектомЖаргон как средство повышения эффективности работы над проектом
Жаргон как средство повышения эффективности работы над проектом
 
управление заинтересованными сторонами
управление заинтересованными сторонамиуправление заинтересованными сторонами
управление заинтересованными сторонами
 
Всегда ли рыба гниет с головы, или развитие управленческих компетенций
Всегда ли рыба гниет с головы, или развитие управленческих компетенцийВсегда ли рыба гниет с головы, или развитие управленческих компетенций
Всегда ли рыба гниет с головы, или развитие управленческих компетенций
 
Варианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовВарианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектов
 
User stories and use cases - Клаудия Заика
User stories and use cases - Клаудия ЗаикаUser stories and use cases - Клаудия Заика
User stories and use cases - Клаудия Заика
 
Подходы к спецификации изменений
Подходы к спецификации измененийПодходы к спецификации изменений
Подходы к спецификации изменений
 
Customer Journey Mapping для бизнес-аналитиков и не только
Customer Journey Mapping для бизнес-аналитиков и не толькоCustomer Journey Mapping для бизнес-аналитиков и не только
Customer Journey Mapping для бизнес-аналитиков и не только
 
To requirements and beyond...
To requirements and beyond...To requirements and beyond...
To requirements and beyond...
 
Коммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономииКоммуникация при различной структуре мышления - таксономия против фолксономии
Коммуникация при различной структуре мышления - таксономия против фолксономии
 
Моделирование бизнес-процессов: методы и инструменты
Моделирование бизнес-процессов: методы и инструментыМоделирование бизнес-процессов: методы и инструменты
Моделирование бизнес-процессов: методы и инструменты
 
Подбор кандидатов на позицию бизнес аналитика
Подбор кандидатов на позицию бизнес аналитикаПодбор кандидатов на позицию бизнес аналитика
Подбор кандидатов на позицию бизнес аналитика
 
Заинтересованные лица: классификация, выявление, анализ, техники
Заинтересованные лица: классификация, выявление, анализ, техникиЗаинтересованные лица: классификация, выявление, анализ, техники
Заинтересованные лица: классификация, выявление, анализ, техники
 

More from SQALab

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировкуSQALab
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаSQALab
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиSQALab
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияSQALab
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...SQALab
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testingSQALab
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженSQALab
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииSQALab
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовSQALab
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовSQALab
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsSQALab
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеSQALab
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеSQALab
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестированиеSQALab
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"SQALab
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовSQALab
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных системSQALab
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросSQALab
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...SQALab
 

More from SQALab (20)

Готовим стажировку
Готовим стажировкуГотовим стажировку
Готовим стажировку
 
Куда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщикаКуда приводят мечты? или Искусство развития тестировщика
Куда приводят мечты? или Искусство развития тестировщика
 
Оптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержкиОптимизация Selenium тестов и ускорение их поддержки
Оптимизация Selenium тестов и ускорение их поддержки
 
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программированияАвтоматизация 0.0: 0 - бюджет, 0 - опыт программирования
Автоматизация 0.0: 0 - бюджет, 0 - опыт программирования
 
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
Нагрузочное тестирование нестандартных протоколов с использованием Citrix и J...
 
Continuous performance testing
Continuous performance testingContinuous performance testing
Continuous performance testing
 
Конфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нуженКонфиги вместо костылей. Pytestconfig и зачем он нужен
Конфиги вместо костылей. Pytestconfig и зачем он нужен
 
Команда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихииКоманда чемпионов в ИТ стихии
Команда чемпионов в ИТ стихии
 
API. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советовAPI. Серебряная пуля в магазине советов
API. Серебряная пуля в магазине советов
 
Добиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестовДобиваемся эффективности каждого из 9000+ UI-тестов
Добиваемся эффективности каждого из 9000+ UI-тестов
 
Делаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIsДелаем автоматизацию проектных KPIs
Делаем автоматизацию проектных KPIs
 
Вредные привычки в тест-менеджменте
Вредные привычки в тест-менеджментеВредные привычки в тест-менеджменте
Вредные привычки в тест-менеджменте
 
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииМощь переполняет с JDI 2.0 - новая эра UI автоматизации
Мощь переполняет с JDI 2.0 - новая эра UI автоматизации
 
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качествеКак hh.ru дошли до 500 релизов в квартал без потери в качестве
Как hh.ru дошли до 500 релизов в квартал без потери в качестве
 
Стили лидерства и тестирование
Стили лидерства и тестированиеСтили лидерства и тестирование
Стили лидерства и тестирование
 
"Давайте не будем про качество"
"Давайте не будем про качество""Давайте не будем про качество"
"Давайте не будем про качество"
 
Apache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектовApache.JMeter для .NET-проектов
Apache.JMeter для .NET-проектов
 
Тестирование геолокационных систем
Тестирование геолокационных системТестирование геолокационных систем
Тестирование геолокационных систем
 
Лидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопросЛидер или босс? Вот в чем вопрос
Лидер или босс? Вот в чем вопрос
 
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
 

EARS: The Easy Approach to Requirements Syntax

  • 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