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

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

Требование техники

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

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

Требование инженерного процесса

Это четырехэтапный процесс, который включает в себя:

• Технико-экономическое обоснование
• Сбор требований
• Спецификация требований к программному обеспечению
• Проверка требований к программному обеспечению

Давайте посмотрим на процесс вкратце –

Технико-экономическое обоснование

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

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

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

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

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

Сбор требований

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

Спецификация требований к программному обеспечению

SRS – это документ, созданный системным аналитиком после сбора требований от различных заинтересованных сторон.

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

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

Учимся понимать бизнес-требования / Кирилл Белявский

SRS должен придумать следующие функции:

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

Проверка требований к программному обеспечению

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

• Если они могут быть практически реализованы
• Если они действительны и согласно функциональности и области программного обеспечения
• Если есть какие-то неясности
• Если они завершены
• Если они могут быть продемонстрированы

Процесс выявления требований

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

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

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

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

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

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

Существуют различные способы определения требований

Интервью

Интервью являются сильной средой для сбора требований. Организация может проводить несколько типов интервью, таких как:

• Структурированные (закрытые) собеседования, в которых каждая информация, подлежащая сбору, определяется заранее, они твердо следуют шаблону и предмету обсуждения.
• Неструктурированные (открытые) интервью, где информация для сбора не определена заранее, более гибкая и менее предвзятая.
• Устные интервью
• Письменные интервью
• Индивидуальные интервью, которые проводятся между двумя людьми за столом.
• Групповые интервью, которые проводятся между группами участников. Они помогают выявить любые недостающие требования, так как вовлечены многочисленные люди.

Обзоры

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

Анкетирование

Документ с предварительно определенным набором объективных вопросов и соответствующими вариантами передается всем заинтересованным сторонам для ответа, которые собираются и компилируются.

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

Анализ задач

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

Анализ предметной области

Каждое программное обеспечение попадает в какую-то доменную категорию. Опытные люди в этой области могут оказать большую помощь в анализе общих и конкретных требований.

мозговая атака

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

макетирования

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

наблюдение

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

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

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

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

• Очистить
• Правильный
• последовательный
• Последовательный
• понятный
• модифицируемый
• проверяемый
• Приоритетное
• недвусмысленный
• прослеживаемый
• Достоверный источник

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

Категория:Требования

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

Требования к продукту

Требования к продукту (бизнес-требования, требования стейкхолдеров) — это описания “черного ящика”, которые формулируются пользователями, рынком, внешними регуляторами, и, обычно, описывают проблемную область:

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

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

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

Формально высказывания о “прозрачном ящике” не называются требованиями, поэтому некоторые авторы предлагают называть их “ограничениями” (свободы творчества инженерной команды). Неплохо бы понимать в каждом проекте, что является требованиями, а что является ограничениями. Прежде всего вы должны удовлетворить требования.

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

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

Требования к системе

Требования к системе (system requirements) — требования, достаточные для разработки системы, которые формулируются архитекторами, проектировщиками и аналитиками на основе анализа требований к продукту и описывают:

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

Их разрабатывает инженер по требованиям в ходе так называемой “аналитической” работы (хотя в этой работе кроме анализа требований стейкхолдеров и присутствует синтез системных требований).

К требованиям к системе предъявляют множество самых разных требований:

• непротиворечивость,
• полнота,
• проверяемость
• и т.д.

Требования по ГОСТ 34

Модальность

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

• нейтральные высказывания о мире, суть которых непонятна без указания модальности. Например, «длина дана как 16».
• алетическая (alethic) модальность, относящаяся к возможности существования: пока воплощения системы ещё нет, возможны варианты определений системы для разных возможных вариантов будущего воплощения системы. Например, «длина может быть 16».
• деонтическая (deontic) модальность, относящаяся к обязыванию и дозволению. Например, «длина должна быть 16». Собственно, это и есть главная модальность “требований”, требования — это то, что должно быть, рекомендуется быть, разрешается быть, обязательно или необязательно и т.д.
• темпоральная (temporal) модальность, связанная со временем. Например, «длина была 16 три года назад».
• доксическая (doxastic) модальность, связанная с верой. «Я верю, что длина дана как 16». Доксическая модальность важна для квалификации (удостоверения того, что требования выполнены — вера в то, что система соответствует её определению).

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

Требования связаны с инженерными обоснованиями: они переформулируются как «декларации» (claim) разработчиков о соответствии — т.е. «я верю, что длина равна 16», а затем это высказывание доказывается по логическим правилам рациональной аргументации (помним, что логика — это дисциплина, занимающаяся правильностью рассуждений). Эти доказательства проводятся “как в суде” — и для этого даже заводится “дело” (assurance case, как раз от “судебного дела” — с вариантами dependability case, safety case, security case, requirement case, architectural quality case). Обзор по инженерным обоснованиям приведён тут.

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

1. Требования назначения (operational requirements) — относятся к назначению и целям создания системы. Совокупность этих требований должна описывать конечное состояние мира после того, как система будет развернута и начнет использоваться. Иногда их называют «требования к возможностям системы», «необходимые возможности». — требования, выведенные из портебностей стейкхолдеров после анализа потребностей.
2. Функциональные требования (functional requirements) — требования, определяющие функцию, которую должна быть способна выполнить система или элемент системы (ISO 24765) — требования, выведенные из сценариев использования. Самые распространённые практики инженерии требований — это выявление функций (поведения) системы из каких-то сценариев взаимодействия (user stories, use cases).
3. Требования к показателям функционирования (performance requirements) — описывают насколько хорошо система должна выполнять предъявленные к ней требования (минимальные числовые пороговые значения).
4. Требования к реализации (requirements) — требуемые характеристики и атрибуты физического воплощения системы и ограничения на ее конструкцию, внешний вид, общие свойства, вес, мощность, материал, ограничения на внешние интерфейсы.
5. Нефункциональные, “требования качества” (например, требованиям надёжности, ремонтопригодности, доступности, безопасности и т.д., так называемые “-ости”, по- английски это будут “ilities” — reliability, repairability, availability, safety, etc.).

Но есть замечание Donald Firesmith, что “не бывает нефункциональных требований” — ибо все эти «требования качества» это абсолютно функциональные требования, характеризующие функции системы с точки зрения каких-то стейкхолдеров, обычно не рассматривающихся в сценариях “пользования”.

Главный источник ошибок в проекте — это неведение относительно наличия каких-то требований. Впрочем, классификация может помочь, если вы зададите себе вопрос: какие виды требований вы ещё не рассматривали для вашего проекта?

Свойства качества (внешние)

Подробнее про требования защитоспособности (выделенные на рисунке выше) можно посмотреть в презентации Дональда Файерсмита — и там же можно посмотреть на презентацию по целеориентированной инженерии требований Яна Александера.

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

• SysML
• AP 233
• RIF
• ISO 29148
• ITU Z.151 (URN=GRL+UCM)
• другие языки из подхода GORE: выражение оппозиции цели-средства (ends – means)

• i*
• RFLP
• ArchiMate
• MBRD
• OMG BMM
• Planguage

Практики ЖЦ требований по ISO 15288

Жизненный цикл требований стейкхолдеров

1. Подготовиться (идентифицировать стейкхолдеров, определить стратегию определения потребностей стейкхолдеров и требований, получить или купить обеспечивающую систему и сервисы)
2. Определить потребности стейкхолдеров (определить контекст использования, идентифицировать потребности стейкхолдеров, приоритизировать и отобрать потребности, определить потребности стейкхолдеров и их обоснование)
3. Разработать Концепцию функционирования (operational concept) и другие концепции жизненного цикла (определить набор сценариев, определить взаимодействия пользователей и системы)
4. Преобразовать потребности стейхколдеров в требования стейкхолдеров (идентифицировать ограничения на инженерные решения, идентифицировать требования стейкхолдеров и все функции для требований качества, гармонизировать требования стейкхолдеров)
5. Анализировать требования стейкхолдеров (анализировать полное множество требований стейкхолдеров, определить критические показатели результативности, которые позволят оценить технические достижения, получить обратную связь от стейкхолдеров – валидировать, устранить все проблемы и противоречия со стейкхолдерами)
6. Управлять определением потребностей стейкхолдеров и требованиями (получить явное согласие на требования стейкхолдеров, поддерживать трассировку потребностей и требований, обеспечивать сведения по базисам)

Жизненный цикл требований к системе

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

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

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

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

Важно понимать, что:

1. требования системной инженерии — определения “чёрного ящика”, которые могут даже не содержать слово “требования” в своих рабочих продуктах и не содержать слов, обозначающих деонтическую модальность — быть без слов “должно”, “возможно”, “обязательно” и т.д.
2. требования совсем необязательно являются бумажными документами-текстами. Они вполне могут храниться в какой-то БД (в рамках какой-то “информационной системы управления требованиями” — DOORS, IRQA и т.д.) в виде отдельных пронумерованных текстовых описаний или в виде компьютерной модели, численной или логической.

Управление требованиями и инженерия требований

1. Управление требованиями — дисциплина инженерного менеджмента (логистическая, “инженерного документооборота”), она заключается в том, чтобы предоставить средства хранения требований и сообщения о них всем тем, кто в них нуждается. Для того, чтобы управлять требованиями, нужно их сначала иметь.
2. Инженерия требований — это поддисциплина системной инженерии, занимается разработкой требований. Главная часть инженерии требований — это реверс-инжиниринг использующей (над)системы (using system) для того, чтобы получить описания “чёрного ящика”.

Требования к требованиям

Требования к требованиям по ISO 29148

Требования к группе требований:

1. Полнота (complete)
2. Согласованность с другими (consistent)
3. Выполнимость (affordable, проходимы по бюджетам и срокам)
4. Ограниченность (bounded)

Требования к одному требованию:

1. Необходимость (necessary) — Требование представляет определённую заинтересованным лицом характеристику, отсутствие которой приведёт к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования.
2. Абстрактность (abstract) —
3. Недвусмысленность (unambiguous) — Требование кратко определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.
4. Согласованность с другими (consistent) — Требование не противоречит другим требованиям и полностью соответствует внешней документации.
5. Полнота (complete) — Требование полностью определено в одном месте и вся необходимая информация присутствует.
6. Лаконичность (concise) — Требование не может быть разбито на ряд более детальных требований без потери завершённости.
7. Достижимость (feasible) — Требование может быть реализовано в пределах проекта.
8. Трассируемость (traceable) — Связь с вышестоящими и нижестоящими требованиями.
9. Проверяемость (verifiable) — Реализованность требования может быть определена через один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

Другое

• Единичность — Требование описывает одну и только одну вещь.
• Актуальность — Требование не стало устаревшим с течением времени.

Состояния

OMG Essence определяет следующие состояния для альфы «Требования» и контрольные вопросы для проверки каждого состояния:

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

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

❑ Есть ясная возможность, которую будет адресовывать новая система.

❑ Стейкхолдеры согласны с назначениемновой системы.

❑ Ясно, что будет считаться успехом для новой системы.

❑ Стейкхолдеры имеют одинаковое понимание пределов предлагаемого решения.

❑ Технология описания требований согласована.

❑ Механизмы управления требованиями наличествуют.

❑ Приоретизационная схема ясна.

❑ Ограничения определены и приняты во внимание.Допущения ясно сформулированы.

❑ Происхождение требований ясно.

❑ Обоснование требований ясно.

❑ Противоречивые требования идентифицированы и ими занимаются.

❑ Требования сообщают существенные характеристики поставляемой системы.

❑ Наиболее важные сценарии использования системы могут быть объяснены.

❑ Приоритетность требований ясна.

❑ Влияние реализации требований понимается.

❑ Команда понимает, что должно быть обеспечено и соглашается обеспечить это.

❑ Скорость изменений к согласованным требованиям относительно низка и под контролем.

❑ Польза, обеспечиваемая реализацией требований, ясна.

❑ Части возможности, удовлетворяемые требованиями, ясны.

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

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

❑ Система, реализующая требования, принимается стейкхолдерами, как заслуживающая эксплуатации.

❑ Нет никаких невыполненных единиц требований, которые не дают принять систему как полностью удовлетворяющую требованиям.

❑ Система, принята стейкхолдерами как полностью удовлетворяющая требованиям.

Страницы в категории «Требования»

Показаны 3 страницы из 3, находящихся в данной категории.

Источник: sewiki.ru

Функциональные Нефункциональные

На рисунке имеются 7 столбцов. Нумерацию будем вести слева направо и сверху вниз. Например блок 2.1 это «Модели процессов» и т. д. Начнем с блока 1.

1. Основы программных требований

(Software Requirements Fundamentals)

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

1.1 Определение требований (Definition of a Software Requirement).

Здесь дается само понятие «требования», как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования. Необходимо обратить внимание на следующие определения понятия «требование» (на основе стандарта IEEE Standard Glossary of Software Engineering Terminology, 1990):

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

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

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

1.2 Требования к продукту и процессу (Product and Process Requirements).

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

Например, работа в режиме 24 x 7 (как бизнес-требование) наверняка приведет к ограничению выбора тех или иных программных средств, платформ развертывания и архитектурных решений. Напомним, что режим 24 x 7 означает работу 24 часа в сутки, 7 дней в неделю.

1.3 Функциональные и нефункциональные требования (Functional and Non-functional Requirements).

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

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

1.3.1. Потребности – отражают проблемы бизнеса, а так же персоналии и процессы, которые должны быть соотнесены с приобретением и использованием системы.

1.3.2. Группа функциональных требований, включает:

· Бизнес – требования – определяют высокоуровневые цели заказчика разрабатываемого программного обеспечения.

· Пользовательские требования – описывают цели и задачи пользователей системы, которые должны достигаться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования.

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

1.3.3. Группа нефункциональных требований, включает:

· Бизнес-правила связанные с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т.д.

Часто можно видеть недостаточное внимание к такого рода требованиям сотрудников ИТ — департаментов, в основном, технических специалистов, вовлеченных в проект. По сути, бизнес-правила определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса.

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

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

· Не следует путать «внешние интерфейсы» и «пользовательские интерфейсы». Вопросы организации пользовательского интерфейса весьма важны в данной категории требований. Однако, «внешний интерфейс» это взаимодействие с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга эксплуатации – по сути взаимодействие с «внешним миром». Функциональные же требования направлены на решение бизнес – потребностей, с пользовательским интерфейсом.

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

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

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

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

Необходимо сделать несколько важных замечаний по бизнес-правилам.

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

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

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

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

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

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

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

Анализируя различные источники на предмет работы с features, следует отметить следующее:

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

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

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

· Features могут быть разного уровня детализации – от выражения высокоуровневых возможностей системы (например, «Расчет заработной платы …»), до достаточно конкретных требований (например, «Автоматическое уведомление Клиента по e-mail о резервировании товара на складе»).

1.4 Независимые свойства (Emergent Properties).

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

Требования с количественной оценкой (Quantifiable Requirements).

Это требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность «столько-то запросов в секунду».

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

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

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

Например, в устах системного администратора специализированного программного обеспечения, привыкшего работать в командной оболочке Unix/Linux, объясняющего свои потребности аналитику, фиксирующему запросы пользователя и привыкшего оперировать Microsoft Office.

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

Например, так – средний показатель ошибок оператора не должен превышать 2% от объема вводимой информации и 85% пользователей должны дать положительную оценку прототипу пользовательского интерфейса на этапе опытной эксплуатации.

Такие требования должны однозначно отвечать на вопросы, предполагающие ответы с численными величинами – как часто? насколько быстро? в каком количестве? и т.п.

Большинство требований с количественной оценкой относится к атрибутам качества. В качестве примера можно привести реальное требование, присутствующее в реальном проекте по электронному документообороту:

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

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

1.6 Системные требования и программные требования (System Requirements and Software Requirements).

Данное разделение базируется на определении «системы», данном INCOSE (International Council on Systems Engineering) «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы».

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

2. Процесс работы с требованиями (Requirements Process)