- •Письменные лекции по дисциплине «Разработка и анализ требований»
- •Лекция 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. Сравнение систем управления требованиями
5.12. Бизнес-процессы
Основные процессы:
регистрация абитуриента (подача документов),
внесение изменений в личное дело абитуриента,
ежедневный отчет перед руководством о результатах приема документов,
отчет для городской приемной комиссии,
публикация поименного списка,
публикация приказа на зачисление.
Вспомогательные процессы:
резервное копирование данных.
Процессы управления:
актуализация данных перед началом работы приемной кампании,
передача данных о результатах зачисления заинтересованным подразделениям.
5.13. Бизнес-правила
Бизнес-правило — это положение, определяющее или ограничивающее какие-либо стороны бизнеса; требования, которые необходимо реализовать на основании каких-либо документов извне (требования, которые идут не от заказчика).
БП-1. Начало приема документов <дата>.
Источник: Правила приема в вуз на ___ год.
БП-2. Окончание приема документов <дата>.
Источник: Правила приема в вуз на ___ год.
БП-3. Количество направлений, на которые абитуриент может участвовать в конкурсе в данном вузе.
Источник: Правила приема вуз на ___ год.
5.14. Диаграмма прецедентов
5.14.1. Прецедент «Обновление данных перед началом приемной кампании»
Вариант 1.
Вариант 2.
Вариант 3.
5.15. Диаграмма развертывания системы «Абитуриент»
5.16. Список классов
1. Абитуриент
2. Личное дело
3. Факультет
4. Направление
5. ФОК
6. Свидетельство ЕГЭ
7. Документ об образовании
8. Фотография
9. Заявление
10. Расписка
11. Предмет
12. Приоритет зачисления
5.17. Диаграмма классов
5.18. Функциональные требования
Класс Абитуриент |
Класс ФОК |
|
|
5.19. Класс Личное дело
<Данные абитуриента>
Дата подачи.
Место хранения.
Статус:
— документы не приняты,
— документы приняты,
— участвует в конкурсе (на направление ___),
— зачислен,
— документы выданы.
Лекция 6. Методы структурного анализа требований к по
6.1. Средства структурного анализа
SADT (Structured Analysis and Design Technique).
IDEF (Icam DEFinition):
IDEF0 — методология, используемая для создания функциональной модели.
IDEF1 — методология, используемая для создания информационной модели и др.
ICAM (Integrated Computer-Aided Manufacturing) — программа интегрированной компьютерной модернизации производства США.
Стандарт: Р 50.1.028-2001 Информационные технологии поддержки жизненного цикла продукции.
DFD (Data Flow Diagrams) — функциональная модель.
ERD (Entity-Relationship Diagrams) — информационная модель.
STD (State Transition Diagrams) — динамическая модель.