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

Август 2, 2022

Главная
Информатика
Требования к ПО

Содержание

2. Требования к ПО Определение требований разных уровней: Пользовательские требования - описание на естественном языке (плюс поясняющие
3. Функциональные и нефункциональные требования Требования к программной системе часто классифицируются как: Функциональные требования. Это перечень сервисов,
4. Нефункциональные требования Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы,
5. Нефункциональные требования Системная цель Система должна быть простой в эксплуатации для опытного оператора и сводить количество
6. Нефункциональные требования
7. Требования предметной области В качестве примера рассмотрим требования к библиотечной системе. Стандартный пользовательский интерфейс, предоставляющий доступ
8. Пользовательские требования Вместе с тем при описании требований на естественном языке могут возникнуть различные проблемы. Отсутствие
9. Системные требования
10. Структурированный язык спецификаций Стандартные формы, используемые для специфицирования функциональных требований, должны содержать следующую информацию: Описание функции
11. Создание спецификаций с помощью PDL PDL - program description language. Этот язык подобен таким языкам программирования,
12. Рекомендуется использовать PDL в следующих ситуациях Если описываемая ситуация состоит из последовательности простых действий и важен
13. Описание интерфейса сервера печати с помощью PDL Interface PrintServer { // определение абстрактного сервера печати //
14. Документирование системных требований Документ, содержащий требования, также называемый спецификацией системных требований, - это официальное предписание для
15. Структура спецификации требований.
16. Разработка требований Разработка требований - это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего
17. Анализ осуществимости Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика? Можно ли реализовать систему, используя
18. Формирование и анализ требований Процесс формирования и анализа требований проходит через ряд этапов: Анализ предметной области.
19. Аттестация требований Во время процесса аттестации должны быть выполнены различные типы проверок документации требований. Проверка правильности
20. Аттестация требований Существует ряд методов аттестации требований, которые можно использовать совместно или каждый в отдельности. Обзор
21. Управление требованиями Постоянные требования. Это относительно стабильные требования, которые исходят из основной деятельности организации и касаются
22. Классификация изменяемых требований
24. Скачать презентацию

Слайд 2

Требования к ПО
Определение требований разных уровней:
Пользовательские требования - описание на естественном

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

Слайд 3

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

Это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Нефункциональные требования. Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не функциональными.
В действительности чёткой грани между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя.

Слайд 4

Нефункциональные требования
Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся

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

Слайд 5

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

и сводить количество его ошибок к минимуму.
Проверяемое нефункциональное требование
Опытному оператору должны быть доступны все системные функции после двух часов обучения работе с данной системой. После такого обучения среднее число ошибок оператора не должно превышать двух за рабочий день.
В идеале нефункциональные требования должны выражаться через количественные показатели, которые можно объективно измерить. В таблице приведены показатели, с помощью которых можно специфицировать нефункциональные системные требования.

Слайд 6

Нефункциональные требования

Слайд 7

Требования предметной области
В качестве примера рассмотрим требования к библиотечной системе.
Стандартный

пользовательский интерфейс, предоставляющий доступ ко всем библиотечным базам данных, должен основываться на стандарте Z39.50.
Для обеспечения авторских прав некоторые документы должны быть удалены из системы сразу после получения. Для этого, в зависимости от желания пользователя, эти документы могут быть распечатаны или на локальном системном сервере, или на сетевом принтере.

Слайд 8

Пользовательские требования
Вместе с тем при описании требований на естественном языке могут

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

Слайд 9

Системные требования

Слайд 10

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

следующую информацию:
Описание функции или объекта.
Описание входных данных и их источники.
Описание выходных данных с указанием пункта их назначения.
Указание, что необходимо для выполнения функции.
Если это спецификация функции, необходимо описание предварительных условий (предусловий), которые должны выполняться перед вызовом функции, и описание заключительного условия (постусловия), которое должно быть выполнено после завершения выполнения функции.
Описание побочных эффектов (если они есть).

Слайд 11

Создание спецификаций с помощью PDL
PDL - program description language. Этот язык

подобен таким языкам программирования, как Java и Ada, но более абстрактен. Достоинством применения PDL для создания спецификации является то, что в такой спецификации можно проверить синтаксис и семантику существующими программными средствами. Эти проверки позволяют удалить ошибки и несогласованность в описании требований.

Слайд 12

Рекомендуется использовать PDL в следующих ситуациях
Если описываемая ситуация состоит из последовательности

простых действий и важен порядок их выполнения. Описывать такие последовательности действий на естественном языке порой затруднительно, поскольку их выполнение может сопровождаться вложенными условиями или они могут повторяться циклически.
Если необходимо специфицировать аппаратные или программные интерфейсы, так как практически во всех спецификациях системных требований приходиться описывать интерфейсы.
Наиболее эффективным способом разработки спецификаций является сочетание подхода, основанного на PDL, с использованием структурированного естественного языка. В этом случае формализованные записи на естественном языке используются для описания системы в целом, а PDL - для описания последовательностей управляющих действий или для детализированного описания интерфейсов.

Слайд 13

Описание интерфейса сервера печати с помощью PDL
Interface PrintServer {
//

определение абстрактного сервера печати
// требуется: интерфейс Printer, интерфейс PrintDoc
// предоставляет функции: initialize (инициализация),
// print (печать),
// displayPrintQueue (отображение очереди на печать),
// cancelPrintJob (удаление файла из очереди),
// switchPrinter (переключение между принтерами)
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob ( Printer p, PrintDoc d ) ;
void SwitchPrinter ( Printer p1, Printer p2, PrintDoc d ) ;
}//PrintServer

Слайд 14

Документирование системных требований
Документ, содержащий требования, также называемый спецификацией системных требований, -

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

Слайд 15

Структура спецификации требований.

Слайд 16

Разработка требований
Разработка требований - это процесс, включающий мероприятия, необходимые для создания

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

Слайд 17

Анализ осуществимости
Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика?
Можно

ли реализовать систему, используя существующие на данный момент технологии и не выходя за пределы заданной стоимости?
Можно ли объединить систему с другими системами, которые уже эксплуатируются?

Слайд 18

Формирование и анализ требований
Процесс формирования и анализа требований проходит через ряд

этапов:
Анализ предметной области. Аналитики должны изучить предметную область, где будет эксплуатироваться система.
Сбор требований. Это процесс взаимодействия с лицами, формирующими требования. Во время этого процесса продолжается анализ предметной области.
Классификация требований. На этом этапе бесформенный набор требований преобразуется в логически связанные группы требований.
Разрешение противоречий. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми. На этом этапе определяются и разрешаются противоречия такого рода.
Назначение приоритетов. В любом наборе требований одни из них будут более важны, чем другие. На этом этапе совместно с лицами, формирующими требования, определяются наиболее важные требования.
Проверка требований. На этом этапе определяется их полнота, последовательность и непротиворечивость.

Слайд 19

Аттестация требований
Во время процесса аттестации должны быть выполнены различные типы проверок

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

Слайд 20

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

каждый в отдельности.
Обзор требований. Требования системно анализируются рецензентами.
Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.
Генерация тестовых сценариев. В идеале требования должны быть такими, чтобы их реализацию можно было протестировать. Если тесты для требований разрабатываются как часть процесса аттестации, то часто это позволяет обнаружить проблемы в спецификации. Если такие тесты сложно или невозможно разработать, то обычно это означает, что требования трудно выполнить и поэтому необходимо их пересмотреть.
Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в базе данных.

Слайд 21

Управление требованиями
Постоянные требования. Это относительно стабильные требования, которые исходят из основной

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

Слайд 22

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

Содержание

Требования к ПО Определение требований разных уровней:Пользовательские требования - описание на естественном

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

Нефункциональные требования Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся

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

Нефункциональные требования

Требования предметной областиВ качестве примера рассмотрим требования к библиотечной системе. Стандартный

Пользовательские требования Вместе с тем при описании требований на естественном языке могут

Системные требования

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

Создание спецификаций с помощью PDL PDL - program description language. Этот язык

Рекомендуется использовать PDL в следующих ситуацияхЕсли описываемая ситуация состоит из последовательности

Описание интерфейса сервера печати с помощью PDL Interface PrintServer { //

Документирование системных требований Документ, содержащий требования, также называемый спецификацией системных требований, -

Структура спецификации требований.

Разработка требованийРазработка требований - это процесс, включающий мероприятия, необходимые для создания

Анализ осуществимости Отвечает ли система общим и бизнес-целям организации-заказчика и организации-разработчика? Можно

Формирование и анализ требованийПроцесс формирования и анализа требований проходит через ряд

Аттестация требований Во время процесса аттестации должны быть выполнены различные типы проверок

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

Управление требованиямиПостоянные требования. Это относительно стабильные требования, которые исходят из основной

Классификация изменяемых требований

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