Документ обсуждает управление требованиями и тестированием в разработке программного обеспечения, подчеркивая важность связи между требованиями и тестированием для предотвращения дефектов. Описываются методы анализа требований, управления изменениями и практические аспекты разработки требований, включая их классификацию и рецензирование. Также рассматриваются ключевые требования и недостатки, возникающие из недостаточного отделения проблем от решений.

1. Управление требованиями и тестирование ПО Начальник отдела тестирования Якимович Алексей

2. Введение Требования тесно связаны с тестированием. В широком смысле тестирование - это любое действие , направленное на выявление и предотвращение дефектов в системе, где дефект - это отклонение от требований. Таким образом , в дополнение к классическим методам тестирования, ( таким как модульное, системное и т.п. ) , тестирование - это еще рецензирование и анализ требований.

3. Содержание Введение в общий процесс разработки и анализа требований Практические аспекты разработки требований Процесс рецензирования требований

4. 1. Введение в общий процесс разработки и анализа требований.

5. V- модель разработки и тестирования

6. Управление изменениями При внесении изменения необходимо выполнить следующую работу : Принять или отклонить изменение Согласовать изменение с заказчиком Организовать работы по переделке

7. Создание и анализ связей между требованиями (1) В контексте бизнеса связи показываются как: Стратегии бизнеса конкретизируются как Задачи бизнеса которые воплощаются как Организация бизнеса и бизнес процессов

8. Создание и анализ связей между требованиями (2) В контексте системного проектирования связи показываются как: Пользовательские требования ( stakeholder requirements) удовлетворяются Системные требования которые разделяются на Подсистемы которые реализуются как Компоненты

9. Выгоды использования связей Большая уверенность в достижении целей – Всегда можем показать, как мы их достигнем. Возможность оценить влияние изменений. Возможность оценить вклад подрядчиков. Возможность контролировать ход работ. Возможность оценить выгоду от реализации.

10. Создание и анализ связей между требованиями (3) Стрелка указывает источник информации!

11. Создание и анализ связей между требованиями (4) Методы анализа связей требований Методы анализа Описание Поддерживаемый процесс Анализ влияния Что будет если изменить это требование? Управление изменениями Анализ последствий Нам это действительно нужно? Анализ экономической целесообразности Анализ покрытия Все ли учтено? Проектирование, отчетность по прогрессу

12. Создание и анализ связей между требованиями (6)

13. Создание и анализ связей между требованиями (6)

14. Требования в области проблем и в области решений(1) Уровень требований Область Точка зрения Цель Пользовательские требования Область проблем Пользователь ( представитель заинтересованной стороны) Определяет - ЧТО пользователь желает достичь с помощью создаваемой системы. Избегаем решений! Системные требования Область решения Аналитик Абстрактно определяет – КАК система будет удовлетворять пользовательским требованиям. Системные спецификации (архитектура системы) Область решения Архитектор Определяет – КАК конкретная архитектура системы будет удовлетворять системным требованиям.

15. Требования в области проблем и в области решений(2) Отсутствие разделения между проблемами и решениями может привести к следующим негативным последствиям: Недостаточное понимание существующих проблем Невозможность определить границы ( scope) системы, т.е. невозможно понять, какой функционал должен входить, а какой- нет Доминирование разработчиков в дискуссиях о системе, поскольку единственные известные требования формулируют в терминах реализации, а не в терминах проблем Невозможность нахождения наилучшего решения из-за ограничения свободы в выборе решения Вывод: Нужно жестко отделять описания проблем от решений!

16. Стратегия проверки(1) Связи типа «удовлетворяет/удовлетворяется» отражают процесс получения производных требований из входящих требований. Стратегия проверки- это набор проверочных мероприятий, проверяющих удовлетворенность требованиий. Каждая проверка подразумевает следующие аспекты: тип проверки фаза, когда проверка осуществляется тестовый стенд для проверки критерий успеха

17. Требования и тестирование

18. Стратегия проверки(2)

19. Простой метод анализа требований - CRUD Для любого объекта должны быть известны ответы на следующие вопросы: C reate - Кто и как создает объект? R ead - Как и где можно прочитать информацию об объекте? U pdate - Кто и как может изменить информацию об объекте? D elete – Кто и как может удалить объект?

20. Нефункциональные требования – FURPS + F unctionality - Feature set, Capabilities, Generality, Security U sability - Human factors, Aesthetics, Consistency, Documentation R eliability - Frequency/severity of failure, Recoverability, P redictability, Accuracy, Mean time to failure P erformance - Speed, Efficiency, Resource consumption, Throughput, Response time S upportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Portability, Localizability + R equirement s for Design , Implementation , I nterface , etc “ Плохой архитектор проектирует функциональные требования, а хороший- нефункциональные… “ Можно продолжить: “ Плохой аналитик/тестировщик ….. ” ))

21. 2. Практические аспекты разработки требований .

22. Требования к требованиям Требования должны предоставлять следующие возможности: Однозначная идентификация Классификация - по важности, типу, срочности в реализации,…. Статус с разных точек зрения – рецензирования, удовлетворения, проверки,.. Анализировать каждое требование в контексте документа, т.е. в окружении других требований Нахождения требования по контексту, классификации и другим признакам Установления связей между требованиями …

23. Приложения для разработки требований Оптимальные приложения для работы с требования должны совмещать преимущества баз данных и текстовых документов! Например: Rational Requisite Pro 8.0, Telelogic Doors … Базы Данных Текстовый Документ Преимущества : Легко Нумеровать, Классифицировать, Трассировать, Сортировать, Отслеживать изменения… Качество отдельного требования высокое! Преимущества : Видение всего документа в целом. Качество документа в целом высокое! Недостаток: Теряется целостность видения документа. Качество всего документа низкое!! Недостаток: Неудобно нумеровать, классифицировать, и т.д Качество отдельного требования низкое! Примеры: Enterprise Architect, Rational Requisite Pro 6.0,… MS Word)

24. Понятие «Ключевых требований» Key User Requirement (KUR) или Key Performance Indicators (KPI) Ключевое Требование подразумевает отрицательный ответ на вопрос: На пользовательском уровне: «Если решение не предполагает < эту > возможность (функцию, опцию, т.д.), стану ли я в этом случае ее приобретать?» На системном уровне: «Если система не обеспечивает < этого > , будет ли система все еще нужна мне?» Ключевые требования позволяют держать в фокусе цели и задачи проекта. Обсуждение/изменение ключевых требований должно происходить с большим вниманием и осторожностью.

25. Элементарные связи

26. Расширенные связи с аргументом удовлетворения Расширенные связи & - и ( conjunction) – для реализации аргумента удовлетворения нужно выполнение всех требований or - или (disjunction) – для реализации аргумента удовлетворения нужно выполнение любого из требований = - требование может быть «спущено» без изменений на более низкие уровни

27. Классификация Требований Первичная классификация – место в контексте документа. Множественная вторичная классификация по следующим группам: Идентификация, Характеристики, Приоритет/Важность, Источник и владелец, Контекст, Процессы и Статусы, … Введение классификации с начала работы с требованиями не требует больших трудозатрат. Классификация упрощает анализ требований на непротиворечивость, полноту, связанность и согласованность.

28. Baselines Baseline – это фиксирование состояния требований в какой-либо момент времени, например, когда заказчик отрецензировал требования, перед началом фазы разработки, т.п. Baselines можно сравнить между собой – чтобы понять, как изменились требования.

29. Рецензирование требований На что обращать внимание: Хаос – требование должно быть сконцентрировано на самом важном «Лазейки» - например фраза «если это необходимо» Более одного требования в одном параграфе (союз И знак!) Рассуждения Размытые понятия и слова – напр.- часто, нормально, типично, т.п. Неопределенные термины – удобный, универсальный, гибкий Желаемое выдано за требуемое – напр. 100% надежный, приятный для пользователей, безопасный, обрабатывать неожиданные сбои, не должен никогда ломаться, и тп

30. 3. Процесс рецензирования требований .

31. Процесс рецензирования

32. Не допускается рецензирование черновиков документов. Обсуждение замечаний на общем собрании – не более 2х минут. Инспектор следит за готовностью документа к рецензированию. В рецензировании может участвовать заказчик + вся команда исполнителей! + приглашенные эксперты. Обязательная проверка внесения изменений. Не нужно изобретать велосипед. Процедура хорошо прописана и известна - www.processimpact.com/reviews_book/ . Можно использовать ПО для организации процесса рецензирования, но лучше иметь еще и личные встречи. Рецензирование документации

33. Вопросы ?

34. Контактная информация [email_address]