Методологические подходы и средства поддержки процессов разработки программного обеспечения организационно-экономических систем. Коротко о главном

– Пользовательские требования – определяют набор пользовательских задач, которые должна решать программная система, а также способы (сценарии) их решения.

– Функциональные требования – характеризуют предполагаемое поведение системы в виде набора определенных действий, которые описываются в системной спецификации (англ. system requirement specification, SRS).

– Нефункциональные требования – набор условий, которым должна соответствовать программная система.

К нефункциональным требованиям относятся:

– Ограничения на программные интерфейсы, в том числе к внешним системам.

– Требования к атрибутам качества.

– Требования к применяемому оборудованию и ПО.

– Требования к документированию.

– Требования к дизайну.

– Требования к безопасности и надёжности.

– Требования к показателям назначения (производительность, устойчивость к сбоям и т.п.).

– Требования к эксплуатации и персоналу.

– Прочие требования и ограничения (мобильность, автономность и т.п.).

Источники требований:

– Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)

– Нормативное обеспечение организации (регламенты, положения, уставы, приказы)

– Текущая организация деятельности объекта автоматизации

– Модели деятельности (диаграммы бизнес-процессов)

– Представления и ожидания потребителей и пользователей системы

– Журналы использования существующих программно-аппаратных систем

– Конкурирующие программные продукты

Свойства требований

Методы выявления требований

– Интервью, опросы, анкетирование.

– Мозговой штурм, семинар.

– Наблюдение за производственной деятельностью.

– Анализ нормативной документации.

– Анализ моделей деятельности.

– Анализ конкурентных продуктов.

– Анализ статистики использования предыдущих версий системы.

Все требования должны поддаваться проверке. Наиболее распространенная методика проверки – тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, обзор дизайна).

Нефункциональные требования, неподдающиеся проверке на программном уровне, должны быть отдельно документированы. Во многих случаях они могут быть преобразованы из требования к продукту в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B.