Please enable JavaScript.

Coggle requires JavaScript to display documents.

SWEBOK Классификация требований к программному обеспечению - Coggle…

- - - - Бизнес
        Зачем создаётся продукт, какие и чьи
        проблемы он решает, какие
        возможности он кому предоставляет, и,
        отчасти, как он будет создаваться.
      - Пользовательские
        Кто и как взаимодействует с продуктом.
      - Функциональные
        Как устроен продукт и его функционал.
    - - Продукт
      - Процесс
    - - Функциональными
        описывают функции
        которые выполняет ПО
      - Нефункциональные
        требования накладывают
        определённые ограничения
    - - Полнота
        Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.
      - Ясность
        Требование, которое сформулировало ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
      - Корректность и согласованность
        Требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня.
      - Верифицируемость
      - Необходимость и полезность при эксплуатации
        Необходимость требований пользователя может вытекать из соответствующих бизнес-требований. Кроме того, требования пользователя могут мотивироваться эргономичностью продукта и особенностями его отдела (подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований.
      - Осуществимость
        Требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами.
      - Трассируемость
        Повысить управляемость проектом: при изменении отдельно взятого требования становится понятно - какие из проектных, рабочих и других артефактов подлежат изменению
      - Упорядоченность по важности
        Приоритет требования представляет собой количественную оценку степени значимости требования. Приоритеты требований обычно назначает представитель Заказчика.
    - - Системные
        Описание примерных характеристик, которым должен соответствовать компьютер для того, чтобы на нём могло использоваться какое-либо определённое программное обеспечение.
      - Программные
        Совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
  - - - Пользователи
        Могут описать задачи, которые он будет решать.
      - Заказчики
        Целевой рынок ПО.
      - Аналитики
      - Регуляторы
        Делают всё по закону.
      - Инженеры для ПО
    - - Распределение ресурсов
      - Инициация и определение содержания
      - Управление в программной инженерии
    - - Покрытие работы с требованиями с точки зрения стандартов и моделей услуг процесса
      - Измерение и количественная оценка
      - Планирование и реализация процесса улучшения
  - - - Интервьюирование
        
        Проведение интервью
        
        Завершение
        
        Подготовка
      - Анкетирование
      - Наблюдение
        Через наблюдение, а возможно и участие, аналитики получают информацию о происходящих день за днём операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы, которые никогда бы не появились, если бы аналитик только читал или разговаривал с экспертами.
      - Самостоятельное описание требований
        Документы - источник, они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - способ получить представление о системе и сформулировать вопросы к экспертам.
      - Совместный семинар
        Первое правило мозгового штурма - "полный запрет на любую критику". Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
      - Прототипирование
        Ключевая выявления требований в большинстве современных методологий. Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика.
      - Разработка + проведение переговоров и нахождение компромисса
    - - Заказчик
      - Группа работников предприятия
      - Документация
      - Важные работники предприятия
      - Прототип
        Программный прототип это как зеркало в котором видно отражение того, как понял исполнитель требования заказчика.
  - - - Функциональные и не функциональные требования ОПРЕДЕЛЕНИЕ #
    - - Природа проблемы
      - Экспертиза и опыт инженеров
      - Требования заказчика к процессу
      - Доступность методов и инструментов
      - Внутрикорпоративные стандарты и
        регламент
      - Культура разработки
    - - Стандарт ISO12207
      - Модель Захмана
      - TOGAF
  - - - Терминологические
        неопределённости
      - Отсутствие о представления
        классификации требований
      - Фокусировка на деталях
        пользовательского интерфейса
      - Излишние акцентирование внимания на
        деталях реализации
      - Слабая формализация бизнес-процессов
  - - - Смещение внимания с целевых функций прототипа и как следствие неудовлетворение пользователей
      - Превращение прототипа
        в реальную систему
  - - - Приёмочный текст