Формирование требований и проектирование программной системы
Требования к программному обеспечению – совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
Требования могут выражаться в виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях.
Этапу разработки требований часто предшествует технико-экономическое обоснование, или концептуальная фаза анализа проекта. Для ЭИС это, как правило, бизнес-моделирование.
Стадии фазы разработки требований:
– выявление;
– оценка целостности и реализуемости;
– документирование;
– согласование.
Разработка требований к ПО – процесс выявления, формулирования, анализа, документирования и верификации требований, подлежащих выполнению в программном обеспечении (ПО). В его ходе системный аналитик формирует реестр требований, который оформляется в виде документа, а также может быть занесен в автоматизированную систему управления требованиями.
Уровни требований к ПО.
– Бизнес-требования – определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
– Пользовательские требования – определяют набор пользовательских задач, которые должна решать программная система, а также способы (сценарии) их решения.
– Функциональные требования – характеризуют предполагаемое поведение системы в виде набора определенных действий, которые описываются в системной спецификации (англ. system requirement specification, SRS).
– Нефункциональные требования – набор условий, которым должна соответствовать программная система.
К нефункциональным требованиям относятся:
– Ограничения на программные интерфейсы, в том числе к внешним системам.
– Требования к атрибутам качества.
– Требования к применяемому оборудованию и ПО.
– Требования к документированию.
– Требования к дизайну.
– Требования к безопасности и надёжности.
– Требования к показателям назначения (производительность, устойчивость к сбоям и т.п.).
– Требования к эксплуатации и персоналу.
– Прочие требования и ограничения (мобильность, автономность и т.п.).
Источники требований:
– Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
– Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
– Текущая организация деятельности объекта автоматизации
– Модели деятельности (диаграммы бизнес-процессов)
– Представления и ожидания потребителей и пользователей системы
– Журналы использования существующих программно-аппаратных систем
– Конкурирующие программные продукты
Свойства требований
Методы выявления требований
– Интервью, опросы, анкетирование.
– Мозговой штурм, семинар.
– Наблюдение за производственной деятельностью.
– Анализ нормативной документации.
– Анализ моделей деятельности.
– Анализ конкурентных продуктов.
– Анализ статистики использования предыдущих версий системы.
Все требования должны поддаваться проверке. Наиболее распространенная методика проверки – тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, обзор дизайна).
Нефункциональные требования, неподдающиеся проверке на программном уровне, должны быть отдельно документированы. Во многих случаях они могут быть преобразованы из требования к продукту в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B.
Конец ознакомительного фрагмента.