Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

Лекция



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

В данном обзоре мы углубимся в мир требований, рассматривая их анализ, разнообразные виды, ключевые атрибуты, и связь с SWEBOK (Guide to the Software Engineering Body of Knowledge). Мы проанализируем, как требования формируют фундаментальные основы для разработки, обеспечивают понимание функциональных и нефункциональных аспектов проектов, и способствуют эффективному управлению всем жизненным циклом разработки. Наше исследование охватит не только сущность требований, но и то, как их анализ и правильное управление влияют на успех проектов и соответствие созданных продуктов ожиданиям заказчика и стандартам инженерии программного обеспечения.

Рассмотрим ледущие вопросы:

  • Цикл жизни задачи
  • Разновидность требований
  • анализ требований
  • Что такое Exit/Acceptance Criteria
  • Подводные камни и понятие Consistency

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

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

  • • Корректность
  • • Недвусмысленность
  • • Полнота набора требований
  • • Непротиворечивость набора требований
  • • Проверяемость (тестопригодность)
  • • Трассируемость
  • • Понимаемость

Анализ требований — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей, а также документирование. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.

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

Анализ требований включает три типа деятельности:

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

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

Фазы анализа требований

Процесс анализа требований к информационной системе включает следующие фазы:

  • Разработка требований
    • Выявление требований
    • Анализ требований
    • Спецификация требований
    • Проверка требований
  • Управление требованиями

Выявление и анализ требований

Идентификация стейкхолдеров

Стейкхолдер — физическое лицо или организация, имеющая права, долю, требования или интересы относительно системы или ее свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC 15288:2008, ISO/IEC 29148:2011).

Опрос стейкхолдеров

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

Сеансы совместного развития требований (СРТ)

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

Спецификация требований

Списки требований

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

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

Преимущества

  • Обеспечивает контрольный список требований.
  • Обеспечивает договор между заказчиками и разработчиками.
  • Для большой системы может обеспечить описание высокого уровня.

Недостатки

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

Альтернативы спискам требования

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

Измеримые цели

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

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

Прототипы (опытные образцы)

В середине 1980-х прототипирование (англ. prototyping) рассматривалось как решение проблемы анализа требований. Прототипы — макеты системы. Макеты дают возможность пользователям представить систему, которая еще не построена. Опытные образцы помогают пользователям представить, на что будет похожа система, и облегчают пользователям принятие проектных решений, не дожидаясь окончания постройки системы. Наибольшие улучшения во взаимопонимании между пользователями и разработчиками часто замечались с введением опытных образцов. Ранние обзоры системы приводят к меньшему количеству изменений на поздних стадиях разработки и следовательно значительно уменьшают затраты.

Однако за следующее десятилетие прототипирование хоть и было признано эффективной техникой, но не решило проблему анализа требований:

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

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

Сценарии использования

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

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

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

Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) является полным описанием поведения системы, которая будет создана. Она включает ряд сценариев использования, которые описывают все виды взаимодействия пользователей с программным обеспечением. Сценарии использования также известны как функциональные требования. В дополнении к сценариям использования, спецификация программного обеспечения также содержит нефункциональные (или дополнительные) требования. Нефункциональные требования — требования, которые налагают дополнительные ограничения на систему (такие как требования эффективности работы, стандарты качества, или проектные ограничения).

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

Типы требований

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

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

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

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

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

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

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

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

Производные требования

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

Известные модели классификации требований включают FURPS и FURPS+, разработанные в Hewlett-Packard.

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

Проблемы стейкхолдеров

Стив Макконнелл, в его книге «Быстрая разработка» , подробно описывает как пользователи могут препятствовать сбору требований:

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

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

Проблемы инженеров / разработчиков

Возможные проблемы, вызванные инженерами и разработчиками во время анализа требований:

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

Решения проблем

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

Методики, введенные в 1990-х — прототипирование, унифицированный язык моделирования (UML), сценарии использования и гибкая методология разработки, — также предназначены для решения описанных выше проблем.

Exit-критерии (exit criteria )

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

Термин Exit-критерии часто используется в "R и D" ( " Исследования и разработки "), но это может быть применимо к любой области , где Реинжиниринг бизнес - процессов является (или может быть) применены. Преимущества "реинжиниринг бизнес - процессов" - включает использование терминов : четкое понимание целей , с использованием языка (и данных) , когда речь идет о (или) измерениях методов для получения сделанных вещей, и принимая научный подход в направлении оценки и совершенствования методов, которые используются.

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

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

Acceptance Criteria

Разве мы строим продукт? И строим ли мы продукт правильно?

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

Каковы критерии приемки?

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

Критерии приемки представляют собой набор утверждений, каждое с четким результатом - годен / не годен , которые определяют функциональные и нефункциональные требования и применяются в Epic, Feature и история Уровеней. Критерии приемки представляют наше "Определение Готово", и Сделал я имею в виду Хорошо сделано.

Причем не возможно частичная приемка: либо критерии приемки удовлетворяется или нет.

Когда определены критерии приемки?

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

Что делает хорошие критерии приемки?

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

Какие. Не как.

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

Форматы критерии приемки

Учитывая / Если / Тогда формат полезный способ определить критерии приемки:

С учетом некоторых предварительных условий Когда я делаю какие-то действия Тогда я ожидаю какого-то результата

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

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

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

Каковы некоторые из проблем или методов, которые Вы нашли при написании критериев приемки?

Введение в анализ требований. Виды и свойства требований. Уровни требований

Стандартное определение понятия «требование»

Стандарт IEEE

  • • Требования к программной системе – это:
  • • Функциональность, необходимая пользователю для решения проблемы или достижения цели.
  • • Функциональность, которая должна быть получена (достигнута) системой или ее компонентами для соответствия контракту, стандарту, спецификации или другим формальным документам.
  • • Документальное представление пп. 1 – 2

Стандарт ISO 12207

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

Другие определения понятия «требование»

Ian Sommerville & Pete Sawyer

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

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

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

Л. Новиков в русской редакции нотации Rational Unified Process

  • • Условие или возможность, которой должна удовлетворять система
  • • A requirement is defined as “a condition or capability to which a system must conform”

Требования – отдельные (дискретные) утверждения, составляющие целостную картину

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

Требование само по себе может иметь набор свойств (атрибутов)

Требования могут иметь сложную структуру отношений и связей (например, иерархическую)

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

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

Область знаний “Программные требования” в SWEBOK (Software Engineering Body of Knowledge)

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

SWEBOK определяет структуру области знаний «Программные требования» и указывает на основные виды деятельности, связанные с разработкой и управлением требованиями

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

Требования к продукту и процессу (Product and Process Requirements) – параметры, относящиеся к продукту или процессу его создания

  • - проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться
  • - отмечается, что ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу
  • - например:
  • - работа в режиме 24 x 7 (как бизнес-требование) наверняка приведет к ограничению выбора тех или иных программных средств, платформ развертывания и архитектурных решений;
  • - в свою очередь, выбор платформы J 2 EE (Java 2 Enterprise Edition) и ее реализации в виде конкретного сервера приложений практически наверняка потребует применения модульного тестирования (Unit testing) как практики процесса разработки и JUnit, как инструмента реализации этой практики

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

: функциональные требования задают “что” система должна делать, т. е. описывают функции, которые выполняет ПО часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase нефункциональные накладывают определенные ограничения, т. е. с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции)

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

Требования с количественной оценкой (Quantifiable Requirements) – требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.

Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы” таким образом, подразумевается, что система является более емким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков

Классификация требований по Карлу Вигерсу

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

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

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

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

Системные требования определяют функциональность и характеристики системы, которую должны построить разработчики, для того чтобы пользователи смогли выполнить свои задачи (в рамках бизнес-требований) Термином системные требования обозначают высокоуровневые требования к продуктам, которые содержат многие подсистемы, то есть системам (IEEE, 1998 с). Говоря о системе, мы подразумеваем программное обеспечение или подсистемы программного обеспечения и оборудования. Люди – часть системы, поэтому определенные функции системы могут распространяться и на людей Классификация требований

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

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

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

Классификация бизнес-правил

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

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

Активаторы операций. Правило, при определенных условиях приводящее к выполнению какихлибо действий, называется активатором операции. Человек может выполнять эти действия самостоятельно. Как вариант, правило может управлять некоторыми программными функциями, благодаря которым приложение при выполнении определенных условий реализует нужную модель поведения. Условия, определяющие выполнение операции, иногда представляют собой сложную комбинацию значений «истина» и «ложь» , выполняющихся для нескольких отдельных условий. Выражение вида «Если <некоторое условие верно или наступило определенное событие>, то <что-то произойдет>» , – это признак, который описывает активатор операции. .

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

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

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

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

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

Существует большое число атрибутов качества.

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

Классификация атрибутов качества

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

Атрибуты, важные для пользователей

Под доступностью понимается запланированное время доступности (up time), в течение которого система действительно доступна для использования и полностью работоспособна. Формально доступность равна среднему времени до сбоя (mean time to failure, MTTF) системы, деленному на сумму среднего времени до сбоя и ожидаемого времени до восстановления системы после сбоя.

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

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

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

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

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

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

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

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

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

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

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

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

Взаимосвязь атрибутов качества

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

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

Позитивные и негативные взаимосвязи атрибутов качества

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

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

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

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

Критерии качества отдельных положений спецификации требований

Критерии качества спецификации требований в целом

Критерии качества отдельных положений спецификации требований

Полнота

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

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

Корректность

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

Осуществимость

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

Необходимость

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

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

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

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

Критерии качества спецификации требований в целом

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

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

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

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

Назначение приоритетов требований

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

Менеджер проекта должен сбалансировать желаемый объем проекта и ограничения, определяемые сроком, бюджетом, людскими ресурсами и качеством. Один из способов достижения этого – убрать (или отложить до более поздней версии) требования с низким приоритетом, когда принимаются новые, более важные требования или изменяются другие условия проекта.

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

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

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

Шкала приоритетов Расстановка приоритетов: Матрица Эйзенхауэра

Один из способов оценки приоритетов предлагает учитывать два измерения: важность и срочность. Каждое требование считается важным либо не важным и срочным либо не срочным. Получаются четыре комбинации для определения шкалы приоритетов:

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

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

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

Требования к программному продукту и к требованиям . Анализ и виды требований, атрибуты, SWEBOK

Таким образом "Требования" играют критическую роль в процессе разработки программного обеспечения и инженерии систем. Вот несколько ключевых выводов по этой теме, включая анализ и виды требований , атрибуты и ссылку на SWEBOK (Guide to the Software Engineering Body of Knowledge).

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

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

    • Понятность и ясность: Требования должны быть понятными и четкими, чтобы избежать недоразумений и ошибок в интерпретации.
    • Полнота: Все существенные аспекты функциональных и нефункциональных требований должны быть учтены.
    • Поддерживаемость: Требования должны быть документированы и легко доступными для всех членов команды разработки.
    • Изменяемость: Требования могут меняться со временем, и процесс управления изменениями должен быть установлен.
    • Отслеживаемость: Необходимы методы отслеживания и верификации, чтобы убедиться, что требования были удовлетворены.
  3. SWEBOK (Guide to the Software Engineering Body of Knowledge): SWEBOK - это справочник, который определяет знания и навыки, необходимые для профессиональной практики инженерии программного обеспечения. Он включает в себя обширный набор знаний и практик, связанных с требованиями, проектированием, разработкой, тестированием и управлением проектами в области программной инженерии.

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

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

Вау!! 😲 Ты еще не читал? Это зря!

Ответы на вопросы для самопроверки пишите в комментариях, мы проверим, или же задавайте свой вопрос по данной теме.

создано: 2015-11-03
обновлено: 2023-10-11
132830



Рейтиг 2 of 10. count vote: 3
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии

Александр
01-12-2020
Ужасный перевод, смысл и идея статьи не понятны.
Админ
01-12-2020
что именно непонятно? какой раздел или понятие?
Лиза
10-03-2021
Статью не возможно читать . Такое чувство , что просто взяли иностранную статью всунули в Гугл переводчик и даже не читая скинули сюда . Просто мозг кипит , набор слов
Админ
10-03-2021
предложите предложения-исправления
Игорь
17-05-2021
Не статья, а набор слов. "Лучшие методы рассматривают составленный список требований просто как подсказки и постоянно спрашивают «почему?», пока не будут выявлены истинные деловые цели" ... что это вообще значит?
Админ
09-06-2021
Лучшие практики используют составленный список требований просто как прототип и постоянно используют вопрос «почему?»., до тех пор, пока не будут обнаружены фактические бизнес-цели. Затем заинтересованные стороны и разработчики могут разработать тесты, чтобы измерить, какой уровень каждой цели был достигнут на данный момент.

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

Качество и тестирование программного обеспечения. Quality Assurance.

Термины: Качество и тестирование программного обеспечения. Quality Assurance.