Требования к разрабатываемому программному продукту. Функциональные и нефункциональные требования

Содержание
  1. Нефункциональные требования к системе: понятие и примеры
  2. Две категории требований
  3. Что относится к категории?
  4. Как определять данные требования?
  5. Деятельность по определению требований к продукту
  6. Роли участников рабочей группы
  7. Сценарий для определения требований
  8. Формирование требований к продукту по сценарию
  9. Нефункциональные требования к программному обеспечению. Часть 1
  10. Нефункциональные требования: какие они бывают
  11. Нефункциональные требования: как их определять
  12. Нефункциональные требования: работа над определением
  13. Анализ
  14. Системный аналитик
  15. Портрет аналитика
  16. Примеры требований
  17. Важные критерии требований
  18. Функциональные и нефункциональные требования к системе
  19. Требования к программному обеспечению
  20. Требования
  21. Бизнес-требования(business requirements)
  22. Требования пользователей (user requirements)
  23. Функциональные требования (functional requirements)
  24. Системные требования (system requirements)
  25. Бизнес-правила (business rules)

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

Требования к разрабатываемому программному продукту. Функциональные и нефункциональные требования

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

Две категории требований

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

Итак:

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

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

Что относится к категории?

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

Однако большое значение имеют и такие нефункциональные требования:

  • Ограничения. То есть условия, ограничивающие выбор каких-либо решений по воплощению в жизнь отдельных требований (или наборов требований). Они сужают разнообразие выбора инструментов, стратегий, средств при разработке как структуры (архитектуры), так и внешнего вида информационного либо программного продукта.
  • Бизнес-правила. Сюда относятся руководящие правила, политика, принципы, положения, как-то ограничивающие определенные аспекты бизнеса. Например, они могут определять состав и правила выполнения каких-либо бизнес-проектов. Что можно отнести в данную категорию? Корпоративную политику, всевозможные правительственные постановления и указы, промышленные стандарты, вычислительные алгоритмы. Все правила, что как-то влияют на разработку системы, продукта, используются во время работы над проектом.
  • Предложения по реализации. В группу входят конкретные предложения, оценивающие возможность применения определенных архитектурных и технологических решений.
  • Внешние интерфейсы. Описание ключевых аспектов взаимодействия продукта с иными системами и операционной средой. Прежде всего, это требования к API системы или продукта, а также требования к API иных систем, с которыми планируется интеграция разрабатываемого продукта.
  • Предложения по проверке, тестированию разрабатываемого программного обеспечения. Это ряд дополнений к требованиям, указывающий, как то или иное требование должно быть протестировано на практике.
  • Юридические требования. К лицензированию продукта, наличию патента и проч.

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

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

  • Ограничения. «Данная разработка ведется только на платформе вендора Х». «При аутентификации пользователя в информационной системе должны использоваться только биометрические методики идентификации».
  • Бизнес-правила. «При отгрузке продукта менеджер обязан запросить у бухгалтера предприятия счет-фактуру и транспортно-товарные накладные». «Заказ будет считаться отмененным, если оплата по счету не поступила поставщику в течение 14-ти дней».
  • Внешние интерфейсы. «Обеспечить запись в журнал разрабатываемой операционной системы таких событий: сообщение о старте и остановке сервиса Х». «Обеспечить запись в журнал разрабатываемой программы параметров данных ее модулей: ядра, сканера, антивирусной базы. Информация должна быть занесена в журнал как при запуске приложения, так и при обновлении его модулей».

Как определять данные требования?

Мы разобрали конкретные примеры нефункциональных требований. А теперь другой важный вопрос: : «Как их определять в отношении конкретного продукта?»

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

Источниками для составления подобных шаблонов разработчики обычно выбирают следующее:

  • ГОСТ (государственный стандарт РФ) 34-й серии.
  • Книга «Разработка требований к программному обеспечению» (автор — К. Вигерс). В частности, нужно обратить внимание на раздел «Приложение Г». В нем содержатся конкретные примеры документации с требованиями.

Давайте рассмотрим теперь, кто конкретно занимается этой работой.

Деятельность по определению требований к продукту

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

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

Чем это важно? Архитектор, скажем, будет воспринимать нефункциональные требования в качестве входных данных для выбора и проектирования архитектуры программы. А группа тестирования будет по ним планировать подходящие сценарии нагрузочного тестирования.

Именно с помощью последних будет проверяться выполнение нефункциональных требований. По большему счету, это касается атрибутов качества.

Роли участников рабочей группы

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

  • Пользователи. Эти участники дают оценку значениям тех параметров, которые и определяют нефункциональные требования.
  • Системный аналитик. Данный участник собирает, анализирует, систематизирует и документирует нефункциональные требования.
  • Ключевые разработчики и системный архитектор. Какую роль выполняет эта группа? Участвуют как в определении, анализе нефункциональных требований, так и проверяют их на степень воплощения в жизнь.
  • Группа тестирования. Также участвует в определении, анализе перечня нефункциональных требований к программе. Дополнительно разрабатывает сценарии тестирования для данных предписаний.

Сценарий для определения требований

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

  1. Система получает сигнал о событии, инициирующем рассылку электронных уведомлений.
  2. Система осуществляет рассылку сообщений пользователям из списка А, используя для этого шаблон Б. Для отправления посланий используется сервис В.
  3. В случае невозможности завершения операции система предпринимает повторную попытку рассылки сообщений.

Формирование требований к продукту по сценарию

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

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

Сами нефункциональные требования должны строго соответствовать целому ряду качественных критериев к их содержанию:

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

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

Источник: https://FB.ru/article/410592/nefunktsionalnyie-trebovaniya-k-sisteme-ponyatie-i-primeryi

Нефункциональные требования к программному обеспечению. Часть 1

Требования к разрабатываемому программному продукту. Функциональные и нефункциональные требования

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

В этой статье я расскажу о следующем:

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

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

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

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

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

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

Примеры ограничений: «Разработка должна вестись на платформе вендора X», «При аутентификации пользователя должны использоваться биометрические методы идентификации».

  • Бизнес-правила — политика, руководящие принципы или положения, которые определяют или ограничивают некоторые аспекты бизнеса, в т.ч. правила, определяющие состав и правила выполнения определенных бизнес-процессов. К бизнес-правилам относятся корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы, которые используются при разработке продукта или системы либо непосредственно влияют на разработку.

Примеры бизнес-правил: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру», «Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым».

  • Внешние интерфейсы — описание аспектов взаимодействия с другими системами и операционной средой. К ним относятся требования к API продукта или системы, а также требования к API других систем, с которыми осуществляется интеграция.

Примеры внешних интерфейсов: «Обеспечить запись в журнал операционной системы следующих событий: сообщения о запуске и остановке сервиса XX»; «Обеспечить запись в журнал параметров модулей программы: сканера, ядра, антивирусных баз (информация должна заноситься в журнал при запуске программы и при обновлении модулей)»

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

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

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

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

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

Книга Карла Вигерса «Разработка требований к программному обеспечению» — в разделе «Приложение Г» этой книги находятся примеры документации требований.

Материалы ГОСТ 34 серии.

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

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

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

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

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

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

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

1. Система получает оповещение о событии, инициирующем рассылку уведомлений. 2. Система осуществляет рассылку оповещений по адресам из списка рассылки X, используя шаблон Y. Для рассылки сообщений используется сервис Z.

3. В случае невозможности завершения рассылки, система предпринимает повторные попытку рассылки.

Источник: https://savepearlharbor.com/?p=231961

Анализ

Требования к разрабатываемому программному продукту. Функциональные и нефункциональные требования

Анализ

last update: 28-07-2020, 20:01 Если заказчик любимый — делаем то, что ему нужно.Если заказчик нормальный — делаем то, что он хочет.

А если заказчик мерзкий — делаем то, что он написал в ТЗ.

Почерпнуть мудрость

  • (PDF) Разработка требований к ПО (Карл Вигерс, 2014) Фундаментально, читать выборочно. В бумаге продаётся издание 2018 года.
  • Принципы работы с требованиями к программному обеспечению. Унифицированный подход (Дин Леффингуэлл). Советую найти издание посвежее. (PDF) Сжатая выборка основных мыслей из книги 2016 года издания
  • (PDF) Разработка и управление требованиями. Практическое руководство пользователя. (Telelogic, 2005)
  • (PDF) Современные методы описания функциональных требований к системам. (Алистер Коберн, 2002). Советую издание посвежее.
  • (PDF) ISO 29148-2018. Systems and software engineering — Life cycle processes — Requirements engineering

ПО для Аналитика

Аналитики — кто?

Основные решаемые задачи:

  1. определение ключевых заинтересованных лиц проекта (Stakeholders), ожидания которых должны быть удовлетворены;
  2. (совместно с Заказчиком) определение Бизнес-требований;
  3. определение Бизнес-ограничений, Требований государственных и международных регуляторов
  4. (совместно с Ключевым пользователем) выявление Пользовательских требований;
  5. (соовместно с менеджером проекта) разработка концепции Проекта
  6. планирование работ с требованиями в рамках проекта (анализ, верификация, проверка качества)
  7. документирование Бизнес и Пользовательских требований
  8. Ведение репозитория требований
  9. (при необходимости) реверс-инжиниринг бизнес-процессов.

Основные создаваемые артефакты

  • Описание моделей Бизнес-процессов As Is
  • описание моделей бизнес-процессов To Be
  • описание Бизнес- и Пользовательских требований
  • обновления репозитория Требований
  • Создание Vision document / Проектной концепции / Рамок проекта / Соглашения о границах проекта

Кто чаще всего становится бизнес-аналитиком: люди с экономическим образованием

Системный аналитик

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

Основные решаемые задачи

  1. (совместно с Системным архитектором) определение границ Системы (разрабатываемого ПО) и контекста её работы
  2. анализ Бизнес-требований и Пользовательских требований, определение Ограничений
  3. участие в разработке Проектного решения (Solution Design)
  4. декомпозиция Бизнес-сценариев на Системные сценарии
  5. создание сценариев использования (use case)
  6. разработка Функциональных и неФункциональных требований, реализующих Системные сценарии
  7. разработка Пользовательских требований в границах Системы
  8. документирование Требований
  9. Ведение репозитория требований

Основные создаваемые артефакты

  • Техническое задание / Спецификация на изменение ПО (SRS)
  • Описание проектного решения (Solution Design).
  • описание Пользовательских требований уровня Системы
  • обновления репозитория Требований

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

Портрет аналитика

  • (опционально) возможные занимаемые ранее позиции работы Бизнес-аналитиком / Системным аналитиком / UX-проектировщиком / Системным архитектором
  • Коммуникативные навыки:
    • Умение устанавливать контакт с незнакомыми людьми;
    • Умение слушать собеседника и держать в голове цель переговоров;
    • Навыки ведения переговоров с бизнес-заказчиком ИТ-доработок;
    • Умение аргументированно отстаивать свою позицию;
    • (опционально) навыки ведения презентаций.
  • Системный анализ. Навыки определения контекста системы, анализа предметной области, структурной декомпозиции объектов предметной области.
  • иметь представление о жизненном цикле ПО. Ориентация в ключевых методологиях разработки: Waterfall, RUP, Agile, Kanban, для гос. заказчиков — ГОСТ 19 и 34;
  • навыки разработки моделей предметной области в нотациях Archimate, BPMN / IDEF0 / IDEF3;
  • знание языка UML, умение разрабатывать диаграммы предметной области (use cases, activity, state, sequence diagrams)
  • навыки работы с БД, знание SQL (PL-SQL), из нереляционных — MongoDB (негласный стандарт)
  • знание технологий интеграции IT-систем (xsd, xml, wsdl, SOAP, REST). Навыки разработки технических заданий на интеграцию ИТ-систем. Желательно знакомство с понятием сервис-ориентированной архитектуры.
  • владение векторными графическими редакторами типа Archi, Visio, draw.io, gliffy, Modelio;
  • (опционально) навыки работы с системами управления требованиями (Rational RequisitePro, DOORS, Jira+ Confluence)
  • (опционально) владение инструментами проектирования/моделирования, самое востребованное на рынке: Archi, Sparx Enterprise Architect и Rational Rose;

Почитать на тему:

  • Кто ты, IT-аналитик? (2020)

О документации

Источник: http://mellarius.ru/analysis

Примеры требований

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

  • Ограничения. «Данная разработка ведется только на платформе вендора Х». «При аутентификации пользователя в информационной системе должны использоваться только биометрические методики идентификации».
  • Бизнес-правила. «При отгрузке продукта менеджер обязан запросить у бухгалтера предприятия счет-фактуру и транспортно-товарные накладные». «Заказ будет считаться отмененным, если оплата по счету не поступила поставщику в течение 14-ти дней».
  • Внешние интерфейсы. «Обеспечить запись в журнал разрабатываемой операционной системы таких событий: сообщение о старте и остановке сервиса Х». «Обеспечить запись в журнал разрабатываемой программы параметров данных ее модулей: ядра, сканера, антивирусной базы. Информация должна быть занесена в журнал как при запуске приложения, так и при обновлении его модулей».

Важные критерии требований

Сами нефункциональные требования должны строго соответствовать целому ряду качественных критериев к их содержанию:

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

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

Источник

Источник: https://ruud.ru/it/36039-nefunkcionalnye-trebovaniya-k-sisteme-ponyatie-i-primery/

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

Требования к разрабатываемому программному продукту. Функциональные и нефункциональные требования

LABA 2

1.1 Классификация требований

Требования разных уровней, это :

· требованияпользователя для обозначения высокоуровневых обобщенных требований;

· системные требованиядля детализированного описания выполняемых системой функций.

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

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

1 Требования пользователяописание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на нее.

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

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

Требования пользователя

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

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

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

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

Количественные формулировки, которые точно определяют атрибуты эффективности и точности, должны составлять часть спецификации мандатных требований. Это означает, что мандатное требование должно быть квалифицированным в таких оценках, как: объем; скорость и точность.

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

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

Требование аппаратного интерфейса точно определяет все или часть компьютерной аппаратуры, на которой надо выполнить программное обеспечение. Указание формулировок марки и модели устройства, физических ограничений, например: размера, веса; эффективности, например: скорости, памяти

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

Требование взаимодействия «человек-компьютер» точно определяет любой аспект интерфейса «пользователь- ПК». Это может включать положение о стиле, языке команд, меню, окнах; форматах сообщений, времени, затрачиваемое на ответ по команде.

Классификация требований к ПО

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

Системные требования определяют, что должна делать система, не показывая при этом механизма ее реализации (как).

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

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

1.

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

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

В спецификацию системных требований входит также спецификация интерфейсов.

Различают три типа специфицируемых интерфейсов.

1. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры.

2. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой.

3. Специальные представления данных, например в виде упорядоченной последовательности двоичных разрядов.

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

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

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

Требования к программному обеспечению

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

3 Требования предметной области.Характеризуют ту предметную область, для которой разрабатывается система. Эти требования могут быть функциональными и нефункциональными.

©2015-2018 poisk-ru.ru Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.

Нарушение авторских прав и Нарушение персональных данных

Источник: https://steptosleep.ru/%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D0%BA-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%BE%D0%BC%D1%83-%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD/

Требования

Требования к разрабатываемому программному продукту. Функциональные и нефункциональные требования

Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.

Бизнес-требования(business requirements)

Бизнес-требования(business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга.

В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document).

Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

Требования пользователей (user requirements)

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

Функциональные требования (functional requirements)

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

Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные вход­ные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых слу­чаях указывается, что система не должна делать.

Эти требования описывают поведение системы и сервисы (функции), которые она выполняет, и зависят от типа разрабатываемой системы и от потребностей пользовате­лей.

Если функциональные требования оформлены как пользовательские, они, как прави­ло, описывают системы в обобщенном виде.

В противоположность этому функциональ­ные требования, оформленные как системные, описывают систему максимально подроб­но, включая ее входные и выходные данные, исключения и т.д.

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

1. Пользователь должен иметь возможность проводить поиск необходимых ему книг и документов или по всему множеству доступных каталожных баз данных или по определенному их подмножеству.

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

3. Каждый заказ должен быть снабжен уникальным идентификатором (ORDER_ID), который копируется в формуляр пользователя для постоянного хранения.

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

Многие проблемы, возникающие при разработке систем, связаны с неточностью и «размытостью» спецификации требований.

Естественно, разработчики интерпретируют требования, допускающие двоякое толкование, так, чтобы систему было проще реализо­вать. Но это толкование может не совпадать с ожиданиями заказчика.

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

Рассмотрим второе требование к библиотечной системе из приведенного выше списка и обратим внимание на выражение «подходящее средство просмотра документов». Библио­течная система может предоставлять документы в широком спектре форматов.

В требова­нии подразумевается, что система должна предоставить средства для просмотра документов в любом формате.

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

Системные требования (system requirements)

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules)

Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Бизнес-правила не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО.

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

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

Нефункциональные требования описывают цели и атрибуты качества.

Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков.

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

* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

Источник: https://www.svellow.com/trebovaniya/

Умный водитель
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: