Московский государственный университет имени М.В.Ломоносова
Опубликован: 18.09.2006 | Доступ: свободный | Студентов: 1878 / 119 | Оценка: 4.32 / 3.36 | Длительность: 27:14:00
ISBN: 978-5-9556-0067-3
Лекция 4:

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

< Лекция 3 || Лекция 4: 12345 || Лекция 5 >

Правила работы с требования к ПО и более общими системными требованиями (к программно-аппаратной системе), определяются следующими двумя стандартами 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 выделяет следующие ошибки, которых необходимо избегать при определении требований.

    • Описание возможных решений вместо требований. Эта информация важна, но должна оформляться в отдельных документах.
    • Слишком детальные спецификации, описывающие требования к слишком мелким элементам системы или описывающие требования, в точности соответствующие характеристикам определенных систем.
    • Слишком сильные ограничения, не вытекающие из реальных потребностей.
    • Нечеткие требования, которые могут быть непроверяемыми и субъективными ("минимизировать уровень погрешности", "удобный для пользователей интерфейс"), или сформулированы в виде, открытом для пополнения неопределенными элементами (с указанием "и т.д." или "включая, но не ограничиваясь следующим...").
    • Несформулированные предположения о режимах работы, свойствах окружения, о готовности других систем или принятии законов и стандартов, находящихся в стадии разработки.
< Лекция 3 || Лекция 4: 12345 || Лекция 5 >
Владислав Нагорный
Владислав Нагорный

Подскажите, пожалуйста, планируете ли вы возобновление программ высшего образования? Если да, есть ли какие-то примерные сроки?

Спасибо!

Лариса Парфенова
Лариса Парфенова

1) Можно ли экстерном получить второе высшее образование "Программная инженерия" ?

2) Трудоустраиваете ли Вы выпускников?

3) Можно ли с Вашим дипломом поступить в аспирантуру?