Функциональные требования к программному обеспечению

Содержание

Слайд 2

Требования могут выражаться в виде текстовых утверждений и графических моделей. В классическом техническом подходе совокупность требований используется

Требования могут выражаться в виде текстовых утверждений и графических моделей. В классическом
на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях. Этапу разработки требований может предшествовать технико-экономическое обоснование или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.

22.12.2021

Слайд 3

22.12.2021

22.12.2021

Слайд 4

Функциональный характер — требования к поведению системы Бизнес-требования Пользовательские требования Функциональные требования Нефункциональный характер — требования к характеру

Функциональный характер — требования к поведению системы Бизнес-требования Пользовательские требования Функциональные требования
поведения системы

22.12.2021

Слайд 5

22.12.2021

22.12.2021

Слайд 6

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

22.12.2021

Интервью, опросы, анкетирование
Мозговой штурм, семинар
Наблюдение за производственной деятельностью, «фотографирование» рабочего

Методы выявления требований 22.12.2021 Интервью, опросы, анкетирование Мозговой штурм, семинар Наблюдение за
дня
Анализ нормативной документации
Анализ моделей деятельности
Анализ конкурентных продуктов
Анализ статистики использования предыдущих версий системы

Слайд 7

Анализ требований[править | править код] При разработке требований часто возникают проблемы двусмысленности, неполноты, и несогласованности

Анализ требований[править | править код] При разработке требований часто возникают проблемы двусмысленности,
отдельных требований. Устранение этих проблем на этапе разработки требований стоит на несколько порядков меньше, чем устранение этих же проблем на поздних стадиях разработки. Для решения и устранения этих проблем существует процесс разработки требований. При разработке требований существует технический компромисс между слишком неопределёнными требованиями и требованиями столь детализированными, что они: требуют много времени для разработки, иногда даже рискуют устареть к концу разработки; ограничивают возможные способы реализации; являются слишком дорогостоящими.

22.12.2021

Слайд 8

Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной

Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств
системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.

22.12.2021

Слайд 9

Требования могут выражаться в виде текстовых утверждений и графических моделей. В классическом техническом

Требования могут выражаться в виде текстовых утверждений и графических моделей. В классическом
подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на определённых требованиях. Этапу разработки требований, возможно, предшествовало технико-экономическое обоснование, или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований) и проверка правильности.

22.12.2021

Слайд 10

Проверка требований Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки— тесты.

Проверка требований Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки—
Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна). Определённые требования, по своей сути, не являются поддающимися проверке. Они включают требования, которые говорят, что система никогда не должна или всегда должна показывать специфическое свойство. Надлежащее тестирование этих требований потребовало бы бесконечного цикла тестирования. Такие требования должны быть переопределены так, чтобы они стали поддающимися проверке. Как указано выше, все требования должны быть поддающимися проверке.

22.12.2021

Слайд 11

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

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

22.12.2021