Анализ предметной области и требования к ПО

Правила работы с требования к ПО и более общими системными требованиями (к программно-аппаратной системе), определяются следующими двумя стандартами IEEE:

• IEEE 830-1998 Recommended Practice for Software Requirements Specifications [7] (рекомендуемые методы спецификации требований к ПО ).

  Описывает структуру документов для фиксации требований к ПО.

  Кроме того, он определяет характеристики, которыми должен обладать правильно составленный набор требований.

  • Корректность или адекватность (соответствие реальным потребностям).
  • Недвусмысленность (однозначность понимания).
  • Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, в которых придется работать системе).
  • Непротиворечивость (согласованность между различными элементами).
  • Упорядоченность по важности и стабильности.
  • Проверяемость (выполнение каждого требования нужно уметь проверять некоторым достаточно эффективным способом — непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам).
  • Модифицируемость (оформление в удобных для внесения изменений структуре и стилях).
  • Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами, модулями и операциями, ответственными за его выполнение, и с тестами, проверяющими его выполнение).
• IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications [8] (руководство по разработке спецификаций требований к системам).

  Описывает правила построения требований для программно-аппаратных систем в целом. Он выделяет следующие необходимые свойства набора требований:

  • Однократное упоминание отдельных требований.
  • Отсутствие пересечений между требованиями.
  • Явное указание связей между требованиями.
  • Полнота.
  • Непротиворечивость.
  • Определение ограничений, области действия и контекста для каждого требования.
  • Модифицируемость.
  • Конфигурируемость, удобство поддержки.
  • Подходящий для определения системы уровень абстракции.

  Кроме того, следующие свойства считаются необходимыми для отдельного требования.

  • Абстрактность — формулировка, независимая от возможных реализаций.
  • Недвусмысленность.
  • Прослеживаемость.
  • Проверяемость.

  Стандарт предписывает определять следующие атрибуты для каждого требования:

  • Уникальный идентификатор.
  • Приоритет, важность реализации с точки зрения пользователей.
  • Критичность для построения и успешности системы с точки зрения аналитиков.
  • Осуществимость с точки зрения готовности пользователей к новой функции, имеющихся технологий и стоимости реализации.
  • Риски высокой стоимости, последствий использования для окружающей среды и пользователей, конфликтов со стандартами и законодательством.
  • Источник (т.е. кто предложил это требование).
  • Тип требования. Возможные типы определяются так (многие из них соответствуют атрибутам качества, рассматриваемым в следующей лекции):
    • Требования на входные данные.
    • Требования на выходные данные.
    • Надежность (reliability, например, среднее время работы между отказами).
    • Работоспособность (availability, например, необходимое отношение времени функционирования к полному времени работы).
    • Удобство сопровождения (maintainability, например, удобство замены компонента).
    • Производительность (performance, например, среднее время ожидания ответа).
    • Доступность (accessibility, например, разные способы доступа для новичков и опытных пользователей).
    • Ограничения окружающей среды (например, максимальный уровень задымленности, при котором гарантируется работоспособность).
    • Эргономичность (ergonomic, например, использование набора цветов, понижающих утомляемость глаз).
    • Безопасность (safety, например, допустимые уровни электромагнитного излучения различных частот).
    • Защищенность (security, например, ограничения доступа для разных пользователей).
    • Требования к оборудованию (например, использование обычной электросети).
    • Транспортируемость (transportability, например, ограничения веса).
    • Удобство обучения (например, включение обучающих материалов).
    • Документированность (например, наличие встроенной документации).
    • Внешние интерфейсы (например, поддержка стандартных форматов документов).
    • Тестируемость (например, поддержка удаленной диагностики).
    • Условия необходимого качества (например, максимально допустимая погрешность производимых измерений).
    • Следование корпоративным и законодательным нормам (например, законам об охране труда).
    • Совместимость с известными системами.
    • Следование стандартам и технологическим нормам.
    • Конвертация данных (например, из старой версии системы).
    • Возможности роста (например, возможное увеличение числа пользователей).
    • Удобство развертывания (например, время, необходимое для приведения в работоспособное состояние).

    В дополнение к перечисленному, стандарт IEEE 1233 выделяет следующие ошибки, которых необходимо избегать при определении требований.
  • Описание возможных решений вместо требований. Эта информация важна, но должна оформляться в отдельных документах.
  • Слишком детальные спецификации, описывающие требования к слишком мелким элементам системы или описывающие требования, в точности соответствующие характеристикам определенных систем.
  • Слишком сильные ограничения, не вытекающие из реальных потребностей.
  • Нечеткие требования, которые могут быть непроверяемыми и субъективными ("минимизировать уровень погрешности", "удобный для пользователей интерфейс"), или сформулированы в виде, открытом для пополнения неопределенными элементами (с указанием "и т.д." или "включая, но не ограничиваясь следующим...").
  • Несформулированные предположения о режимах работы, свойствах окружения, о готовности других систем или принятии законов и стандартов, находящихся в стадии разработки.