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

Август 20, 2022

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

Содержание

2. Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности
3. Требования могут выражаться в виде утверждений и моделей. текстовых графических
4. ТЕКСТОВЫЕ зафиксированная на каком-либо материальном носителе человеческая мысль; в общем плане связная и полная последовательность символов.
5. ГРАФИЧЕСКИЕ художественно-проектная деятельность по созданию гармоничной и эффективной визуально-коммуникационной среды. Графический дизайн вносит инновационный вклад в
6. Требования к программному обеспечению В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования
7. Виды требований по уровням Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и
8. Виды требований по характеру Функциональный характер — требования к поведению системы Бизнес-требования Пользовательские требования Функциональные требования
9. Источники требований Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения) Нормативное обеспечение организации (регламенты, положения, уставы,
10. Качество требований
11. Методы выявления требований Интервью, опросы, анкетирование Мозговой штурм, семинар Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
12. Проверка требований Все требования должны поддаваться проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами
13. Анализ требований При разработке требований часто возникают проблемы двусмысленности, неполноты, и несогласованности отдельных требований. Устранение этих
14. Документирование требований Требования обычно используются как средство коммуникации между различными заинтересованными лицами. Это означает, что требования
16. Скачать презентацию

Слайд 2

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

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

Слайд 3

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

Слайд 4

ТЕКСТОВЫЕ
зафиксированная на каком-либо материальном носителе человеческая мысль; в общем плане связная

и полная последовательность символов.

Слайд 5

ГРАФИЧЕСКИЕ
художественно-проектная деятельность по созданию гармоничной и эффективной визуально-коммуникационной среды. Графический дизайн

вносит инновационный вклад в развитие социально-экономической и культурной сфер жизни, способствуя формированию визуального ландшафта современности.

Слайд 6

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

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

Слайд 7

Виды требований по уровням
Бизнес-требования — определяют назначение ПО, описываются в документе о

видении (vision) и границах проекта (scope).
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде сценариев использования (англ. use case), пользовательских историй (англ. user stories), сценариев взаимодействия (scenario).
Функциональный уровень (функции).

Слайд 8

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

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

Слайд 9

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

(регламенты, положения, уставы, приказы)
Текущая организация деятельности объекта автоматизации
Модели деятельности (диаграммы бизнес-процессов)
Представления и ожидания потребителей и пользователей системы
Журналы использования существующих программно-аппаратных систем
Конкурирующие программные продукты

Слайд 10

Качество требований

Слайд 11

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

рабочего дня
Анализ нормативной документации
Анализ моделей деятельности
Анализ конкурентных продуктов
Анализ статистики использования предыдущих версий системы

Слайд 12

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

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

Слайд 13

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

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

Слайд 14

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

Это означает, что требования должны быть просты и понятны для обычных пользователей и разработчиков.
Спецификацию программного обеспечения часто называют техническим заданием.
За создание спецификации программного обеспечения чаще всего в российской практике отвечает системный аналитик, иногда — бизнес-аналитик.
Для графических моделей требований исторически использовались диаграммы или методологии графического моделирования: ER(IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

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

Содержание

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

ТЕКСТОВЫЕзафиксированная на каком-либо материальном носителе человеческая мысль; в общем плане связная

ГРАФИЧЕСКИЕхудожественно-проектная деятельность по созданию гармоничной и эффективной визуально-коммуникационной среды. Графический дизайн

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

Виды требований по уровням Бизнес-требования — определяют назначение ПО, описываются в документе о

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

Качество требований

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

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

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

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

Похожие презентации