Please enable JavaScript.

Coggle requires JavaScript to display documents.

Управление требованиями (1 . выявление требований :silhouettes:…

- - - - Каких показателей хотят добиться
        
        Бизнес-цели
      - Бизнес-правила. Бизнес-ограничения. Налоговое законодательство. Технические ограничения(языки програмирования, ОС) ГОСТЫ
    - - Зачем и для чего мы делаем это
        
        Юзер стори
    - - ЧТо система будет делать
        
        Какие операции должна выполнять система. Система должна..
    - - Юзабилити - интерфейс
      - Производительность
      - Отказоустойчивость
      - Время отклика
      - Требования к каналам связи
      - Требования к поддержке
  - - - Бизнес - требования
        
        Основные функции(ФИЧИ) информационных систем и ограничения(на Бизнес уровне: ГОсты, законодательство и т.п.)
        
        Заинтересованных лиц(стейкхолдеры) и их потребности(что им необходимо)
        
        Проблемы, которые мы решаем внедрением данного функционала-сервиса-доработки, а также цели проекта(Для чего и зачем мы будет это внедрять и как будем работать с помощью этого решения)
      - Пользовательские требования
        
        Взаимодействие ПО и пользователей( Что хочет пользователь от системы)
        
        Обьекты предметной области(сущности, активности, задачи, обращения) - Можно создать модель Бизнес-обьектов
        
        Бизнес-правила по которым работает бизнес( Пример: Пароль должен содержать N-символов)
      - Системные требования
        
        Функциональные требования
        
        Что должна делать система.Можно описывать в формате Юзер-кейсов."Я, как пользователь, хочу.." или "Система должна..."
        
        Требования к логированию операций
        
        Нефункциональные требования
        
        :!!: КОНЦЕПЦИЯ FURPS :!!:
        
        F - Functionality
        (Требования к функциональности)
        
        U - Usability(Тр-я к удобству использования)
        
        R - Reliability(Тр-я к надежности)
        
        P - Perfomance(Тр-я к производительности)
        
        S - Supportability(Тр-я к поддержке)
  - - - ЧТо он может требовать, что я как аналитик должен от него получить
      - Предоставить описание БПМН процесса
    - - КОманда разработки
      - Тестировщики
      - Аналитики
      - Рук проекта
  - - - Предоставлять изменения без задержек
  - - - Подготовка
        
        Сформулиловать вопросы и повестку встречи и выслать ее на всех
        
        Собраться со всеми ЗЛ(7 чел макс) - Либо ТКС
        
        Пригласить еще одного аналитика и разработчика. Один аналитик ведет, второй фасилицирует(записывает) требования
        
        Начинать и заканчивать вовремя-ВЫглядеть опрятно
      - Проведение
      - Анализ информации
      - Обработка результатов
- - - - Категория 1
        1.1 Требование
        1.2 Требование
        Категория 2
        2.1 Требование
        2.2 Требование
    - - Разбиение задач
        на подзадачи
        
        Оценка решения
    - - Контекстная диаграмма
        
        Выбрать уровень детализации
        
        Представить конечное состояние системы
        
        Нарисовать НАШУ систему в центре
        
        Определить пользователей
        
        Определить внешние системы
        
        Определить потоки вх и исх сообщений
        
        Проверить соответствие потоков
      - Диаграмма данных ДД :checkered_flag:
        Связь бизнес-сущностей (пример ER-diag)
        
        Одинаковый уровень абстракции
        
        Не пытаться создать реализацию(еще слишком рано на этом этапе)
        
        Оперировать определениями\терминами бизнеса
        
        Использовать UML как можно проще
        
        Моделировать итерационно
        (со вторым аналитиком, который не в контексте)
        
        Определить основные сущности
        
        2.Определить связи между ними
        
        Не описывать операцй
        
        Использовать глоссарий
      - Диаграмма последовательностей
        
        Описание взаимодействия Акторов и Систем
      - Диаграмма состояний
        
        Как пример "описание
        Авторизации пользователя"
      - Диаграмма Бизнес-процессов :red_flag:
    - - :question:5 ПОЧЕМУ :question:
        
        Почему не горит лампочка?
        
        Почему не нет напряжения?
        
        ....ПОчему роют у дома?
      - Диаграмма ИШИКАВЫ :recycle:
        ( FISHBONE рыбья голова)
        
        определить СЛЕДСТВИЕ(Проблему)
        
        2.Начните рисовать диаграмму
        
        Добавляйте ветки - КАТЕГОРИИФакторов
        
        Добавляйте в каждую из категорий ФАКТОРЫ
        
        К каждому фактору добавить ПОДФАКТОРЫ
      - Техника "5W" :question:
        
        1.Who - кого затрагивает данная проблема? :
        
        What - в чем проблема?
        
        When- Когда проблема возникает?
        
        Where -Где проблема возникает?
        
        Why - Почему эта проблема так важна?
      - MoSCoW :tada: :smiley: Насколько Фича или
        Дефект важен для заказчика
        
        Приоритезация
        
        M - Must - Должны иметь
        
        S - Should - Хорошо бы иметь
        
        С - Could - можем это иметь,
        если не затрагивает что-то еще
        
        W - Won't - Не хотим сейчас,
        но хорошо бы в будущем
      - CATWOE :warning:
        
        Client - Кто получит
        КОНЕЧНУЮ пользу?
        
        Actors - Кто
        выполняет операции?
        
        Transformations - Как происходит
        преобразование д-х(Интеграция)
        
        World-View - Чем система так хороша?
        
        Owner - Кто может изменить
        конечную цель решения?
        
        Environment - Какие есть
        внешние ограничения?
- - - - Отслеживание версионности
      - фиксация изменений\замечаний
    - - 0 Назначение
        
        Для чего , как его читать и т.п.
      - 1.2. Требования к документу
      - 1.3. Потребители и структура(
        Для кого документ и структура)
      - 1.4. Границы системы
      - 1.5 Ссылки на др. док-ты(КА,ТИВ, ФД)
    - - 3.1. Краткое Описание продукта
      - 3.2 Основные Функции продукта
      - 3.3 Кто пользователь продукта
      - 3.4. Бизнес Ограничения
      - 3.5. Окружения (Какие системы есть)
      - 3.6 Пользовательская документация
      - 3.7 Предположения
        
        "Антитребования""НЕ-". Система
        не будет производить перерасчет ЗП
    - - Структуризация. Способы описания
        
        по ФИчам
        
        ПО вариантам использования
        
        ПО внешним ситуациям
        (Как на контекстной диаграмме)
        
        -ПО ролям
        
        ПО подсистемам
        
        ПО реакциям системы
    - - 4.1 Пользовательский интерфейс
      - 4.2 Интерфейс аппаратного обеспечения
      - 4.3 Интерфейс с другими ПО
      - 4.4 Интерфейс взаимодействвия
    - - 5.1 Быстродействие
      - 5.2. Внешняя безопасность
      - 5.3 Внутренняя безопасность
      - 5.4. Остальные НФТ
        
        Надежность
        
        Отказоустойчивойсть
        
        FURPS!!!
        
        Язык программирования
        
        КАНАЛЫ СВЯЗИ
    - - Определение терминов
    - - ER-диаграмма
        (сущность-связь)
  - - - Много щума и ни о чем
      - нет описания каких-то фич или НФТ
      - Слишком детальное описание
      - Описание одного и того же в разных местах.
        ( BestPractice: "смотри детали там то..."
      - Описание разюросано по документу
      - Неоднозначность (ПРимер : и т.д. и т.п...)
      - Доп ненужная терминология +
        не описана терминология