- •Письменные лекции по дисциплине «Разработка и анализ требований»
- •Лекция 1. Основы работы с требованиями к по
- •1.1. Что такое требования
- •1.2. Классификация программного обеспечения
- •1.3. Разработка требований в модели жизненного цикла по
- •1.4. Участники разработки требований
- •1.4.1. Аналитик требований
- •1.5. Типы требований
- •1.6. Этапы сбора и анализа требований с точки зрения rup
- •1.7. Процесс разработки требований
- •1.7. Разработка концепции продукта
- •1.13. Обзор конкурентов
- •1.13.1. Пример списка возможностей конкурентов
- •1.14. Документ о концепции и границах проекта
- •1.14.1. Положение о концепции
- •1.15. Бизнес-риски
- •1.16. Ограничения проекта и их выявление
- •1.17. Профили заинтересованных лиц
- •1.18. Пример бизнес-требований разных групп пользователей
- •1.19. Приоритеты проекта
- •Лекция 2. Методы выявления требований к по
- •2.1. Сбор требований пользователей
- •2.2. Определение классов пользователей
- •2.3. Характеристики классов пользователей
- •2.4. Представление системных событий и реакции на них
- •2.5.1. Пример crc-карточки
- •2.6. Прототипы (макеты) по
- •2.7. Представление требований пользователя на основе варианта использования
- •2.8. Процессы обработки данных варианта использования
- •2.9. Нефункциональные требования
- •2.10. Уточнение нефункциональных требований
- •2.11. Стандарты практичности (usability)
- •2.12. Бизнес-правила
- •2.12.1. Примеры бизнес-правил
- •Лекция 3. Анализ и моделирование требований к по
- •3.1. Атрибуты качества требований
- •3.2. Статус требования
- •3.3. Полный набор требований по
- •3.4. Представление вводов и выводов по
- •3.5. Полнота нефункциональных требований
- •3.6. Пример трассировки требований.
- •3.6.1. Дочерние требования
- •3.10.1. Оценки разработчиков возможности проверки требований
- •3.11. Определение приоритетов
- •4.3. Диаграммы uml (uml 2.5)
- •4.8. Предметы поведения uml
- •4.9. Отношения uml
- •4.10. Диаграмма Use Case
- •4.11. Диаграмма Use Case (2)
- •4.12. Диаграмма (видов) деятельности
- •5.5. Методики моделирования бизнес-процессов
- •5.6. Программное обеспечение для моделирования бизнес-процессов
- •5.7. Построение модели бизнес-процесса на основе вариантов использования
- •3) Используемые средства
- •5.8. Пример построения спецификации требований
- •5.9. Заинтересованные лица
- •5.10. Эксперты
- •5.11. Словарь (глоссарий)
- •5.12. Бизнес-процессы
- •5.13. Бизнес-правила
- •5.19. Класс Личное дело
- •Лекция 6. Методы структурного анализа требований к по
- •6.1. Средства структурного анализа
- •6.2. Методология sadt
- •6.3.1. Стандартизация методик моделирования в Российской Федерации
- •6.3.2. Диаграмма idef3
- •6.4. Диаграммы потоков данных dfd
- •7.2.2. Спецификация требований к по
- •7.3. Техническое задание (еспд. Гост 19.201-78)
- •7.4. Техническое задание (Информационные технологии гост 34.602-87)
- •7.5. Разработка требований к по встроенных систем
- •7.7. Спецификация требований к интерфейсам
- •7.8. Работа с требованиями в проектах гибкой разработки
- •Лекция 8. Управление требованиями к по
- •8.1. Управление требованиями
- •8.1.8. Атрибуты запроса на изменение
- •8.2. Программные средства управления требованиями
- •8.2.1. Сравнительная характеристика систем управления требованиями
- •8.2.3. Сравнение систем управления требованиями
3.4. Представление вводов и выводов по
Контекстная диаграмма описывает связь нашей системы с внешними сущностями. Внешняя сущность - это что-то внешнее (например, человек, оборудование). Используется для ввода данных, а также вывода данных.
Диаграмма Use Case более подробная, чем контекстная диаграмма, так как показывает не только внешнее окружение, но и функции, которые соответствуют концепции. Каждая из этих функций должна быть потом детализирована. Прецедент (вариант использования) - функция.
3.5. Полнота нефункциональных требований
Есть система, которая принимает запросы от пользователей, и пользователей всегда раздражает долгое получение ответа.
Нормируем в виде требования время, которое пользователь будет тратить на получение ответа.
Пример: время ответа для 90% транзакций будет составлять менее 3 секунд.
3.6. Пример трассировки требований.
Обоснованность: связь высокоуровневых функций и функциональных требований.
Концепция:
8. Система «Абитуриент» должна предоставлять ежедневную сводку о результатах приема документов от абитуриентов.
Функциональные требования:
SR8.1. Система получает данные о количестве принятых документов из базы данных текущего года на текущую дату.
SR8.2. Система использует для сравнения данные сводки на последний день приема из базы данных прошлого года.
SR8.3. Система рисует график в системе координат, ось х которого — ось времени, где каждая точка — очередная дата, ось y — количество поданных заявлений. SR8.4 Диапазон значений по оси x определяется сроком приема документов (Бизнес-правило __), диапазон значений по оси y — от 0 до максимального значения количества принятых документов за предыдущий год*1,2.
SR8.5. Каждая точка графика представляет собой количество документов, принятых от начала приема документов до конкретной даты.
SR8.6. В одних осях строятся два графика: на текущий год от начала приема до текущей даты и предыдущий год на весь период приема документов.
3.6.1. Дочерние требования
SR8.1. Система получает данные о количестве принятых документов из базы данных текущего года на текущую дату.
SR8.2. Система использует для сравнения данные сводки на последний день приема из базы данных прошлого года.
SR8.3. Система рисует график зависимости количества принятых документов за период от даты начала приема документов.
SR8.31. Ось х представляет собой ось времени, где каждая точка — очередная дата, ось y — количество поданных заявлений.
SR8.32. Диапазон значений по оси x определяется сроком приема документов (Бизнес-правило __), диапазон значений по оси y — от 0 до максимального значения количества принятых документов за предыдущий год*1,2.
SR8.33. Каждая точка графика представляет собой количество документов, принятых от начала приема документов до конкретной даты.
SR8.34. В одних осях строятся два графика: на текущий год от начала приема до текущей даты и предыдущий год на весь период приема документов.
Трассировка - если мы берем каждое требование, например, из списка выше, на первом или на уровне втором и мы всегда находим родительское требование и можем подняться до уровня концепции (уровень основного требования).
Требование будет принято, если оно трассируется к основному требованию - это значит, что это требование не выходит за границы нашего требования (основного).
3.7. Дерево требований
3.8. Обоснованность требований: матрица зависимости требований
Конфликтов не должно быть. Пустая клетка — не зависят друг от друга, никаких изменений вводить не нужно. Требования с перекрытием необходимо переформулировать или удалить.
3.9. Корректность и непротиворечивость
Пример:
все служащие старше 65 лет в конце календарного года должны получить премию в размере 10000 рублей;
все служащие, имеющие стаж работы на предприятии 10 лет и более, в конце календарного года должны получить премию 5000 рублей.
Какую премию должен получить сотрудник 65 лет, имеющий стаж работы 15 лет?
Тут происходит некорректность и неоднозначность.
3.10. Проверяемость требований
Требование: система должна быть простой в эксплуатации для опытного пользователя и сводить к минимуму количество ошибок.
Проверяемое требование: опытному оператору должны быть доступны все функции после двух часов обучения работе с данной системой. После такого обучения среднее число ошибок оператора не должно превышать двух за рабочий день.
Невозможно проверить
Оцените возможность проверки следующих требований:
Система должна отвечать на произвольный запрос в течение 500 миллисекунд;
Цифры на экране, показывающем время, должны хорошо выглядеть;
Система должна быть дружественной пользователю;
Система должна экспортировать данные для просмотра в формате, в котором в качестве разделителя используется запятая.
