Требования к ПС

Сентябрь 2, 2022

Главная
Алгебра
Требования к ПС

Содержание

2. 09/02/2023 Содержание Назначение ОТ Принципы формирования ОТ Структура ОТ Стандарт ОТ
3. 09/02/2023 Обзор Разработка ПС – решение проблемы Что нужно создать? Что должно делать ПС? Как должно
4. 09/02/2023 Определение требований Исходный документ для разработки внешнего описания программного средства, передаваемый от пользователя разработчику. Содержит
5. 09/02/2023 Что определяют требования? С одной стороны – услуги или сервисы Что может делать система для
6. 09/02/2023 Типы требований Пользовательские Предложения естественного языка или диаграммы предоставляемых услуг и ограничений на их использование
7. 09/02/2023 Назначение требований
8. 09/02/2023 Уровни требований Функциональные Требования по качеству (нефункциональные) Доменные (относящиеся к классу ПС)
9. 09/02/2023 Функциональные требования Определяют Сервис, предоставляемый системой Реакцию системы на входы Поведение системы в конкретных ситуациях
10. 09/02/2023 Требования по качеству Явно не связаны с конкретной функциональностью системы Могут расширять ее Определяют ограничения
11. 09/02/2023 Классы требований по качеству Требования к продукту Определяют его характеристики – скорость работы, требования к
12. 09/02/2023 Диаграмма требований по качеству
13. 09/02/2023 Доменные требования Отражают характеристики класса продуктов, к которому относится данное ПС Могут определять или ограничивать
14. 09/02/2023 Схема формирования требований
15. 09/02/2023 Источники возникновения требований
16. 09/02/2023 Методы анализа требований Опрос (интервью) Анкетирование Анализ сценариев работы Создание прототипов
17. 09/02/2023 Интервью Закрытые или открытые Перечень вопросов ограничен или нет Контекстные Попытка понять нужды пользователя и
18. 09/02/2023 Принципы контекстного интервью Контекст Выполняется на рабочем месте в течении всего дня Внимание к деталям
19. 09/02/2023 Процесс создания требований Спецификация Уточнение Определение Исследование
20. 09/02/2023 Сценарии Демонстрируют основные действия пользователей и события в системе Отражают реальное использование системы Часто используются
21. 09/02/2023 Содержание сценария Сценарий начинается с общего описания его назначения и содержит следующие элементы: Начальное состояние
22. 09/02/2023 Проблемы использования естественных языков (ЕЯ) Неоднозначность Описание на ЕЯ может быть неверно интерпретировано Чрезмерная гибкость
23. 09/02/2023 Альтернативы естественных языков Структурный ЕЯ Ограниченный алфавит (набор понятий) и грамматика Стандартный способ определения требований
24. 09/02/2023 Формальные спецификации Определение функции или объекта Описание входов и их источников Описание выходов и их
25. 09/02/2023 Графические модели Используют графические объекты и текстовые аннотации к ним Удобны для иллюстрации смены состояний
26. 09/02/2023 Способы управления определением требований Управляемая пользователем разработка Контролируемая пользователем разработка Независимая от пользователя разработка
27. 09/02/2023 Управляемая пользователем разработка Требования определяются заказчиком (госзаказ, военные разработки и др.) Разработчик уточняет требования для
28. 09/02/2023 Контролируемая пользователем разработка Требования формируются заказчиком при участии разработчика Требования утверждаются заказчиком, но не навязываются
29. 09/02/2023 Независимая от пользователя разработка Требования определяются без участия пользователя Требуется хорошее знание предметной области применения
30. 09/02/2023 Кто использует определение требований? Потребители – указывают свои потребности и выбирают ПС на основе информации
31. 09/02/2023 Проверка определения требований Тестируются различные аспекты каждого требования Часто выполняется смежным контролем – совместно разработчик
32. 09/02/2023 Требования к требованиям Верифицируемость – возможность тестировать и оценивать требование Понятность или постижимость –внятность изложения
33. 09/02/2023 Классификация требований Мутирующие требования – изменяются в процессе разработки системы Внезапные требования – возникают в
34. 09/02/2023 Стандарт определения требований Международный стандарт IEEE/ANSI 830-1993 Структура ОТ согласно стандарту: Введение Общее описание Специальные
35. 09/02/2023 Введение IEEE/ANSI 830-1993 Цель документа ОТ Область применения продукта Определения, сокращения Ссылки на другие источники
36. 09/02/2023 Общее описание по IEEE/ANSI 830-1993 Цели применения продукта Функции продукта Классы пользователей Общие ограничения Допущения
37. 09/02/2023 Специальные требования по IEEE/ANSI 830-1993 Требования по качеству и интерфейсу Не имеют стандартной структуры Описывают:
38. 09/02/2023 Приложения по IEEE/ANSI 830-1993 Содержат детальную информацию, относящуюся к данному конкретному ПС Аппаратные требования –
40. Скачать презентацию

Слайд 2

09/02/2023
Содержание
Назначение ОТ
Принципы формирования ОТ
Структура ОТ
Стандарт ОТ

Слайд 3

09/02/2023
Обзор
Разработка ПС – решение проблемы
Что нужно создать?
Что должно делать ПС?
Как должно

функционировать ПС?
Пользователь – не специалист в программировании
Формулирует задачи нечетко
Не представляет возможных проблем реализации

Слайд 4

09/02/2023
Определение требований
Исходный документ для разработки внешнего описания программного средства, передаваемый от

пользователя разработчику. Содержит основные сведения о нуждах пользователя, которые должны быть реализованы в ПС.

Слайд 5

09/02/2023
Что определяют требования?
С одной стороны – услуги или сервисы
Что может делать

система для пользователя
С другой стороны – ограничения
Вводятся условиями функционирования или разработки системы

Слайд 6

09/02/2023
Типы требований
Пользовательские
Предложения естественного языка или диаграммы предоставляемых услуг и ограничений на

их использование
Ориентированы на пользователя
Системные
Документ, содержащий детальное описание сервисов и компонентов системы
Является контрактом между клиентом и разработчиком

Слайд 7

09/02/2023
Назначение требований

Слайд 8

09/02/2023
Уровни требований
Функциональные
Требования по качеству (нефункциональные)
Доменные (относящиеся к классу ПС)

Слайд 9

09/02/2023
Функциональные требования
Определяют
Сервис, предоставляемый системой
Реакцию системы на входы
Поведение системы в конкретных

ситуациях
Зависят от
Типа ПС
Квалификации и категорий пользователей
Типа системы, для которой предназначено ПС
Должны детально описывать ПС

Слайд 10

09/02/2023
Требования по качеству
Явно не связаны с конкретной функциональностью системы
Могут расширять ее
Определяют

ограничения или рамки для характеристик системы
Показатели функционирования
Ограничения процесса разработки
Стандарты
Могут быть более жесткими и критичными, чем функциональные

Слайд 11

09/02/2023
Классы требований по качеству
Требования к продукту
Определяют его характеристики – скорость работы,

требования к ресурсам и т.д.
Организационные требования
Отражают вопросы организации разработки – стандарты, средства, процессы и т.д.
Внешние требования
Формируются внешними факторами – совместимость, патентная чистота и др.

Слайд 12

09/02/2023
Диаграмма требований по качеству

Слайд 13

09/02/2023
Доменные требования
Отражают характеристики класса продуктов, к которому относится данное ПС
Могут определять

или ограничивать функциональность
Позволяют сравнивать ПС с другими представителями домена

Слайд 14

09/02/2023
Схема формирования требований

Слайд 15

09/02/2023
Источники возникновения требований

Слайд 16

09/02/2023
Методы анализа требований
Опрос (интервью)
Анкетирование
Анализ сценариев работы
Создание прототипов

Слайд 17

09/02/2023
Интервью
Закрытые или открытые
Перечень вопросов ограничен или нет
Контекстные
Попытка понять нужды пользователя

и его способ решения задачи
Модель мастер - ученик
Мастер работает и показывает, что он делает
По ходу работы можно задавать вопросы
Не подходят для доменных требований
Разработчик не знаком с терминологией
На некоторые очевидные требования можно не обратить внимания

Слайд 18

09/02/2023
Принципы контекстного интервью
Контекст
Выполняется на рабочем месте в течении всего дня
Внимание к

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

Слайд 19

09/02/2023
Процесс создания требований
Спецификация
Уточнение
Определение
Исследование

Слайд 20

09/02/2023
Сценарии
Демонстрируют основные действия пользователей и события в системе
Отражают реальное использование системы
Часто

используются прототипы
Сценарии могут быть описаны в виде диаграмм UML
Используются для уточнения требований

Слайд 21

09/02/2023
Содержание сценария
Сценарий начинается с общего описания его назначения и содержит следующие

элементы:
Начальное состояние системы
Нормальный поток событий в сценарии
Возможные ошибки и методы их обработки
Другие альтернативные потоки
Конечное состояние системы

Слайд 22

09/02/2023
Проблемы использования естественных языков (ЕЯ)
Неоднозначность
Описание на ЕЯ может быть неверно интерпретировано
Чрезмерная

гибкость
Одни и те же понятия и процессы могут быть описаны по разному
Отсутствие структурности
Описание на ЕЯ трудно формализовать

Слайд 23

09/02/2023
Альтернативы естественных языков
Структурный ЕЯ
Ограниченный алфавит (набор понятий) и грамматика
Стандартный способ определения

требований
Сочетает гибкость ЕЯ и формализм
Пример - псевдокод

Слайд 24

09/02/2023
Формальные спецификации
Определение функции или объекта
Описание входов и их источников
Описание выходов и

их приемников
Описание других необходимых сущностей или функций
Пред- и постусловия
Сторонние эффекты

Слайд 25

09/02/2023
Графические модели
Используют графические объекты и текстовые аннотации к ним
Удобны для иллюстрации

смены состояний или их последовательности
Используются в CASE-системах

Слайд 26

09/02/2023
Способы управления определением требований
Управляемая пользователем разработка
Контролируемая пользователем разработка
Независимая от пользователя разработка

Слайд 27

09/02/2023
Управляемая пользователем разработка
Требования определяются заказчиком (госзаказ, военные разработки и др.)
Разработчик уточняет

требования для себя
В процессе договора существует несколько редакций ОТ

Слайд 28

09/02/2023
Контролируемая пользователем разработка
Требования формируются заказчиком при участии разработчика
Требования утверждаются заказчиком, но

не навязываются им
Наиболее распространенная форма создания ОТ

Слайд 29

09/02/2023
Независимая от пользователя разработка
Требования определяются без участия пользователя
Требуется хорошее знание предметной

области применения ПС
Пригодны для создания ПС широкого применения

Слайд 30

09/02/2023
Кто использует определение требований?
Потребители – указывают свои потребности и выбирают ПС

на основе информации ОТ
Менеджеры – используют ОТ для планирования и управления процессом разработки
Проектировщики – используют ОТ для разработки архитектуры и спецификаций ПС
Тестировщики – используют ОТ для установления валидности системы (соответствия результата исходному заданию)
Инженеры по сопровождению – для понимания архитектуры ПС и взаимодействия между его частями

Слайд 31

09/02/2023
Проверка определения требований
Тестируются различные аспекты каждого требования
Часто выполняется смежным контролем –

совместно разработчик и заказчик
Может быть формальной (с проверкой созданных документов) или неформальной
Может проводиться в виде тестов или ручной имитации функционирования системы

Слайд 32

09/02/2023
Требования к требованиям
Верифицируемость – возможность тестировать и оценивать требование
Понятность или постижимость

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

Слайд 33

09/02/2023
Классификация требований
Мутирующие требования – изменяются в процессе разработки системы
Внезапные требования –

возникают в процессе глубокого понимания системы
Последовательные требования – возникают в процессе введения компьютерной системы в обработку информации
Требования совместимости – зависят от других систем или организационных процессов

Слайд 34

09/02/2023
Стандарт определения требований
Международный стандарт IEEE/ANSI 830-1993
Структура ОТ согласно стандарту:
Введение
Общее описание
Специальные требования
Приложения
Индекс
В

конкретной системе структура может отличаться

Слайд 35

09/02/2023
Введение IEEE/ANSI 830-1993
Цель документа ОТ
Область применения продукта
Определения, сокращения
Ссылки на другие источники
Обзор

остального документа

Слайд 36

09/02/2023
Общее описание по IEEE/ANSI 830-1993
Цели применения продукта
Функции продукта
Классы пользователей
Общие ограничения
Допущения и зависимости

Слайд 37

09/02/2023
Специальные требования по IEEE/ANSI 830-1993
Требования по качеству и интерфейсу
Не имеют стандартной структуры
Описывают:
Внешние

интерфейсы
Производительность
Ограничения по дизайну
Характеристики качества

Слайд 38

09/02/2023
Приложения по IEEE/ANSI 830-1993
Содержат детальную информацию, относящуюся к данному конкретному ПС
Аппаратные требования

– описывают минимальную и оптимальную конфигурацию аппаратуры
Требования к БД – определяют логическую организацию данных, используемых ПС и взаимоотношения между ними.

Требования к ПС

Содержание

09/02/2023Содержание Назначение ОТПринципы формирования ОТСтруктура ОТСтандарт ОТ

09/02/2023ОбзорРазработка ПС – решение проблемыЧто нужно создать?Что должно делать ПС?Как должно

09/02/2023Определение требованийИсходный документ для разработки внешнего описания программного средства, передаваемый от

09/02/2023Что определяют требования?С одной стороны – услуги или сервисыЧто может делать

09/02/2023Типы требованийПользовательскиеПредложения естественного языка или диаграммы предоставляемых услуг и ограничений на

09/02/2023Назначение требований

09/02/2023Уровни требованийФункциональные Требования по качеству (нефункциональные)Доменные (относящиеся к классу ПС)

09/02/2023Функциональные требованияОпределяютСервис, предоставляемый системой Реакцию системы на входыПоведение системы в конкретных

09/02/2023Требования по качествуЯвно не связаны с конкретной функциональностью системыМогут расширять ееОпределяют

09/02/2023Классы требований по качествуТребования к продуктуОпределяют его характеристики – скорость работы,

09/02/2023Диаграмма требований по качеству

09/02/2023Доменные требованияОтражают характеристики класса продуктов, к которому относится данное ПСМогут определять

09/02/2023Схема формирования требований

09/02/2023Источники возникновения требований

09/02/2023Методы анализа требованийОпрос (интервью)Анкетирование Анализ сценариев работыСоздание прототипов

09/02/2023ИнтервьюЗакрытые или открытые Перечень вопросов ограничен или нетКонтекстныеПопытка понять нужды пользователя

09/02/2023Принципы контекстного интервьюКонтекстВыполняется на рабочем месте в течении всего дняВнимание к

09/02/2023Процесс создания требованийСпецификацияУточнениеОпределениеИсследование

09/02/2023СценарииДемонстрируют основные действия пользователей и события в системеОтражают реальное использование системыЧасто

09/02/2023Содержание сценарияСценарий начинается с общего описания его назначения и содержит следующие

09/02/2023Проблемы использования естественных языков (ЕЯ)НеоднозначностьОписание на ЕЯ может быть неверно интерпретированоЧрезмерная

09/02/2023Альтернативы естественных языковСтруктурный ЕЯОграниченный алфавит (набор понятий) и грамматикаСтандартный способ определения

09/02/2023Формальные спецификацииОпределение функции или объектаОписание входов и их источниковОписание выходов и

09/02/2023Графические моделиИспользуют графические объекты и текстовые аннотации к нимУдобны для иллюстрации

09/02/2023Управляемая пользователем разработкаТребования определяются заказчиком (госзаказ, военные разработки и др.)Разработчик уточняет

09/02/2023Контролируемая пользователем разработкаТребования формируются заказчиком при участии разработчикаТребования утверждаются заказчиком, но

09/02/2023Независимая от пользователя разработкаТребования определяются без участия пользователяТребуется хорошее знание предметной

09/02/2023Кто использует определение требований?Потребители – указывают свои потребности и выбирают ПС

09/02/2023Проверка определения требованийТестируются различные аспекты каждого требованияЧасто выполняется смежным контролем –

09/02/2023Требования к требованиямВерифицируемость – возможность тестировать и оценивать требованиеПонятность или постижимость

09/02/2023Классификация требованийМутирующие требования – изменяются в процессе разработки системыВнезапные требования –

09/02/2023Введение IEEE/ANSI 830-1993Цель документа ОТОбласть применения продуктаОпределения, сокращенияСсылки на другие источникиОбзор

09/02/2023Общее описание по IEEE/ANSI 830-1993Цели применения продуктаФункции продуктаКлассы пользователейОбщие ограниченияДопущения и зависимости

09/02/2023Специальные требования по IEEE/ANSI 830-1993Требования по качеству и интерфейсуНе имеют стандартной структурыОписывают:Внешние

09/02/2023Приложения по IEEE/ANSI 830-1993Содержат детальную информацию, относящуюся к данному конкретному ПСАппаратные требования

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