Please enable JavaScript.
Coggle requires JavaScript to display documents.
ТЕОРИЯ: Системный анализ. Разработка и управление требованиями.…
ТЕОРИЯ:
Системный анализ. Разработка и управление требованиями.
Программные инструменты
Для управления требованиями
Requisite Pro
Для разработки требований
Rational Software Architect (Модели)
Методологии
RUP
MSF
Iconix
Agile
XP
Boehm
Разработка требований
Понять бизнес потребность и выявить Заинтересованных Лиц.
1.1 Желательно включить в список ЗЛ IT директора и архитекторов ПО для интеграции.
1.2 Информация о ЗЛ:
ФИО
Должность
Причина заинтересованности
Приоритет удовлетворения ожиданий
По каким вопросам принимает решение
Кто замещает
Телефон
e-mail
2. Интервьюирование ЗЛ:
:recycle: шаблон см.Путь аналитика.стр. 270
:red_flag: Доработать, упростить шаблон
Разработка
STKR
(требований пользователей)
3.1 Занесение результатов Интервью в Requisite Pro (или аналог) с пометкой ANSW - кандидат в требования.
3.2 ANSW -> STKR посредством перефразирования, устранения дубликатов и противоречий.
Любое ANSW в статусах Icorporated, Postpone, Rejected.
STKR удовлетворяет принципам:
тестируемое
реализуемое
ясное для понимания
законченное и полное.
Определение границ системы и создание концепции
4.1
Контекстная диаграмма
(Границы и интерфейсы между системой и внешними сущностями).
4.2 Определение
BREQ
(бизнес требований),
BRULE
(Бизнес правил). Соотнесение их c STKR. Формирование требований
BVISION
=BREQ+BRULE+STKR+SERT+STSTD+CHAR.
4.3 Требования TVISION формируются архитектором, аналитик проверяет соответствие концепции системы STKR,BREQ,BRULE.
:recycle:шаблон концепция системы, см. путь аналитика
#
#
#
Выделение подсистем и описание их функций.
5.1 Варианты:
Use cases
для каждого выявленного актора на основании BVISION и TVISION
Функциональная группировка Use Cases
Создание
функциональных требований
на основании BVISION и TVISION
Функциональная группировка требований.
Создание Use Cases - необязательно.
Гибридный вариант:
Определение высокоуровневых функциональных требований.
Детальная проработка за счет Use Cases
Выявление пользовательских требований
UREQ
- требования пользователей, то есть тех, кто будет работать с системой. Отличие от STKR - STKR предполагает бизнес заинтересованность.
Интервьюирование пользователей.
можно не выделять в отдельный тип, а фиксировать далее в других типах.
Выявление
не функциональных
требований.
Источник не функциональных требований BVISION и TVISION.
GUI:
требования к графическому интерфейсу. также работают дизайнер графических интерфейсов.
ICE
и
DATA
- также работают архитектор и проектировщик базы данных.
DOC и SERT
: специалисты отдела документирования и сертификации.
другие не функциональные требования.
Как выявлять:
Система с точки зрения установки и развёртывания
Качественные параметры работы системы - в том числе количественные характеристики .
Формирование
спецификации требований.
Желательно автоматизировать с случае работы с современными инструментами
возможность работы для заказчиков напрямую с инструментами.
минимизация с использованием Rational SODA for Word
Доп: Участие тест-менеджеров в разработке требований и участие системного аналитика в разработке тест кейсов.
Установка приоритетов требованиям
Экспертиза и утверждение требований
Интервьюирование и анкетирование:
Проведение совещаний:
:recycle:Шаблон протокола совещания см. Путь аналитика.
Управление требованиями:
Атрибуты
Трассировки
Состояния
Совет по управлению изменнениями
Soft skills
Самомотивация
1.1 Учиться у всех
1.2 Не думать о следующей работе
1.3 Развивать чувство драйва
Самоорганизация
2.1 Планирование методом набегающей волны
2.2 Придерживаться плана по времени
2.3 Выделять время на изучение новостей и статей по IT, планирование рабочей недели, подведение итогов дня и анализ и подведение итогов недели, чтение профессиональной литературы по плану развития, систематизацию текущих знаний и навыков
Культура речи
3.1 Чтение классической литературы
Корпоративная культура и этика
4.1 Что сделано, то сделано, что можно сделать чтобы
исправить
недопустить повторения
критикуя - предлагай
База выученных уроков
:red_flag: Определиться, создать
Requisite pro, раз в три месяца перекидывать в coogle
либо coogle
План личного и профессионального развития и хранилище знаний
:red_flag: Определиться, создать
Google Keep или Excel + Google Keep
Проектные коммуникации.
Создание ПУТ (Плана Управления Требованиями)
ПУТ включает:
Типы требований:
Обязательные - STKR, BVISION,TVISION, UREQ,UC, FR, NFR
Типы нефункциональных требований
Атрибуты требований с возможными значениями и ответственными
Необходимость однорангового ревью, ревью архитектора, тест менеджера
Описание состояний и процесса согласования - участники проекта, заказчики через спецификацию
Моделирование:
Бизнес-модель
- бизнес-сценарии, с точки зрения бизнес-акторов и бизнеса компании (источник - STKR, потребитель - модель предметной области, BREQ, BRULE)
#
Модель предметной области
- основные сущности предметной области и их взаимосвязи (Источник - STKR, бизнес-модель,потребитель - концептуальная модель системы)
#
Концептуальная модель системы
- основные сущности системы с атрибутами и их взаимосвязи (Источник - Модель предметной области, потребитель - унифицированное понимание системы + диаграмма пригодности и последовательности (для классов))
Use case model
- описывает варианты использования со стороны акторов и дает едины взгляд на поведение системы (Источник - STKR, потребитель - унифицированное понимание системы c точки зрения её использования акторами, выявление функциональных подстистем, диаграмма пригодности и последовательности, View of participated classes)
#
Модель анализа пригодности варианта использования
- уточняет и проверяет описание варианта использования ((Источник - Описания варианта использования, концептуальная модель системы, потребитель - проверка вариантов использования и выявление классов и кандидатов в классы)
Диаграмма активности
- описывает сценарий варианта использования в виде алгоритма (Источник - детализированный вариант использования системы, потребитель - детальное и наглядное описание алгоритма прецедента)
Диаграмма последовательности
- описывает кандидаты в классы и их взаимодействия в виде обмена сообщениями и вызовами методов друг друга (Источник - Описания варианта использования, сущности концептуальной модели системы, сущности диаграммы анализа пригодности, потребитель - выявление классов и формирование их методов)
Статическая модель анализа
- более пристальный взгляд на состав системы (Источник - концептуальная модель системы, сущности диаграммы анализа пригодности, потребитель - анализ связи между классами кандидатами)
Динамическая модель анализа
- пристальный взгляд на поведенческую составляющую системы.(Источник - Сущности диаграммы анализа пригодности, потребитель - анализ связи между контроллерами)
Логическая модель системы
- модель классов системы с атрибутами и методами, но без деталей реализации (Источник - Описания вариантов использования, диаграммы последовательности, модели анализа, потребитель - модель реализации системы)
Модели разрабатываемые другими ролями
Модель реализации
Модель компонентов
Модель развёртывания
Язык Object Constraint Management