Документ описывает процесс и важность спецификации программных требований (SRS) для разработки программного обеспечения, включая ключевые аспекты, такие как корректность, недвусмысленность, полнота, непротиворечивость, проверяемость, трассируемость и понимаемость требований. Он перечисляет методы анализа и проверки требований, такие как 'peer review' и соответствующие техники. Кроме того, документ упоминает курсы и обучающие программы, предоставляемые учебным центром 'Урансофт'.

1. Учебный центр ИТ
УРАНСОФТ
Учим, устраиваем,
развиваем!

2. Тестирование требований
Software requirements specification, SRS
Программные требования – Software
Requirements – свойства программного
обеспечения, которые должны быть
надлежащим образом представлены в
нём для решения конкретных
практических задач. Данная область
знаний касается вопросов извлечения
(сбора), анализа, специфицирования и
утверждения требований.

3. SRS по К. Вигерсу

4. Пример

5. Требования к требованиям

Корректность

Недвусмысленность

Полнота набора требований

Непротиворечивость набора
требований

Проверяемость (тестопригодность)

Трассируемость

Понимаемость

6. Корректность
Вопрос: На сколько требование
корректно или кто-то допустил ошибку
при написании требования?
Пример: Для стирания последнего знака
используется клавиша [←] (клавиша со
стрелкой)
Описание: Ошибка в требовании.
Правильно будет: «Для стирания
последнего знака используется
клавиша [Backspace] (клавиша со
стрелкой и надписью Backspace)»

7. Корректность
Как находить?

Знание предметной области,

Трассировка требования вверх
(бизнес-требования), трассировка
требований вниз (низкоуровневые
требования — дизайн, макеты,
детальное описание реализации).
Поиск ошибок и нестыковок.

«Peer review» – оценка «коллегами» –
теми, кто занимается той же самой
работой.

8. Недвусмысленность
Могут ли 2 различных человека понять
требование по-разному?
Пример: Сколько будет 2+2х2? 6 или 8?
Описание: Отработка понятия
«Подитог», как в случае (2+2)х2 или
соблюдение «порядка выполнения мат.
действий»

9. Недвусмысленность

10. Недвусмысленность
Как находить?

Проверять «ветвистость» требований:
если есть условия или исключения —
проверять, чтобы они все были
описаны и не было «неописанных
дыр»,

Избегать ветвлений или
форматировать их в таблицы
вариантов.

«Peer review» – оценка коллегами.

11. Полнота требований
Насколько полным является набор
требований?
Если есть секция в SRS, определяющая
функциональность модуля, то вся ли
функциональность этого модуля
покрыта требованиями?
Нет ли дыр?

12. Полнота требований
Как находить?

WBS требований сверху вниз,

Все классы пользователей,

Проверка пограничных значений,

Повторы требований при продолжении
сбора,

Выход за рамки проекта,

Низкий приоритет требования.

13. Непротиворечивость набора
Поиск требований, которые
противоречат друг другу:
1. Это может быть очевидным, когда 2
требования явно говорят
противоположные вещи,
2. но может быть и скрытым, где
противоречивость не очевидна на
первый взгляд.

14. Непротиворечивость набора
Как тестировать?

Обращать внимания на общие
формулировки в требованиях.

Делить на категории и ревьювить их
направленно на предмет
противоречий.

Выделять все требования,
трассирующиеся на одно
верхнеуровневое требование и
анализировать такие наборы.

15. Проверяемость
Один из основных и самых важных
критериев для тестировщиков.
Возможно ли проверить это требование
и убедиться, что оно выполняется?
Пример: в случае возникновения
критической ошибки калькулятор
должен перезагрузиться.
Пример 2: информация на экране
должна отображаться в понятном
пользователю виде

16. Проверяемость
Как тестировать?

«Как я буду это проверять?». Детально
анализировать, и, возможно, вносить
правки в требование (уточнения,
ограничения)

Выявлять общие формулировки,
требующие перебора неопределенного
числа вариантов для проверки
выполнения требования.
(переформулировать требование или
добавить список условий в SRS или
более низкоуровневые документы.)

17. Трассируемость
Любое требование проходит путь от
бизнес-идеи до деталей реализации.
Это может быть 3 уровня требований
(product requirements, software
requirements, detailed design document),
может быть и больше.
Трассируемость — это связь с
требованием выше и требованием
ниже. Кроме того трассируемость
требования (функции) в различных
документах.

18. Понимаемость
Могут ли все участники процесса понять,
что требуется от системы по описанию
требования?
Пример: Калькулятор должен уметь
выделять и начислять НДС.

19. Деление на НОЛЬ

20. Деление на НОЛЬ

21. Курсы Урансофт
(JAVA-01) Введение в Java
(JAVA-02) Основы языка и web-разработки
на Java
(SQA-01) Основы тестирования ПО
(SQA-02) Введение в профессию
тестировщика
(SA-01) Системный анализ в разработке
ПО
(SRS-01) Сбор требований к ПО

22. Спасибо!
Вопросы?
+7 (812) 309-78-59, 438-16-88
Станислав КИМ