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

Изучение

На чтение 4 мин Просмотров 897 Опубликовано 29.03.2022

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

Что такое BRS (спецификация бизнес-требований)?

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

Тестировщик с нуля / Урок 4 / Тестирование требований

Особенности БРС:

1. Это список всех требований, которые запросил клиент.
2. Он включает в себя цель продукта, пользователей, общий объем работ, все упомянутые возможности и функции, а также критерии удобства использования и производительности.
3. Варианты использования, а также диаграммы и таблицы не включены в этот тип статьи.
4. Высшее и среднее руководство, инвесторы в продукты и бизнес-аналитики являются основными пользователями BRS.

Обложки BRS:

1. Цель проекта.
2. Особенности и функциональные возможности продукта.
3. Требования к удобству использования.
4. Пользователи продукта.
5. Масштабы проекта.
6. Требования к производительности.

Что такое SRS (спецификация требований к программному обеспечению)?

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

Функциональные требования. Это документ или часть ТЗ

Особенности СРС:

1. В SRS включены как функциональные, так и нефункциональные критерии, а также варианты использования.
2. Безупречный документ SRS включает в себя то, как программное обеспечение будет взаимодействовать с другим программным обеспечением или когда оно будет встроено в аппаратное обеспечение, но также учитывает будущих пользователей и то, как они будут взаимодействовать с программным обеспечением.
3. Он также включает ссылки на таблицы и диаграммы, которые помогут вам понять все особенности продукта.
4. Документ SRS держит членов команды из всех отделов на одной странице и гарантирует выполнение всех требований.
5. Этот документ также помогает сократить затраты и время на разработку программного обеспечения.

Обложки СРС:

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

Разница между BRS и SRS

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

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

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

Понять друг друга им помогает бизнес-аналитик, он превращает потребности клиента в требования, а требования в задачи для разработчиков. Первоначально это делается путем составления спецификаций требований к программному обеспечению (Software requirements specification или SRS).

Что такое SRS

Software requirements specification — один из самых важных документов в разработке программного обеспечения. Он описывает работу ПО, его функции и нагрузки. Проще говоря, SRS предоставляет всем участникам дорожную карту для проекта.

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

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

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

Как выглядит

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

В YuSMP Group SRS обычно выглядит так:

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

Блок/фича

Функциональности обычно представляем в виде блоков или таблицы, которая включает в себя три раздела — это пользовательская история, бизнес-правила (UseCases) и валидация (на схеме показываем, что требования к фиче выполнены).

Пользовательская история

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

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

Внутри пользовательских историй мы размещаем бизнес-правила или UseCases. Это перечень условий, при котором фича будет работать так, как нужно клиенту.

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

Зачем мы используем SRS

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

Но это еще не все:

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

Еще SRS важен, потому что это единый источник информации, который предотвращает недопонимание как между менеджером проекта и командой, так и между заказчиком и аутсорс-компанией.

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

Сводные документы требований

Текстовая расшифровка восьмого урока курса Введение в профессию аналитика.

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

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

Это достаточно широко известные названия сводных документов. Не только потому что книга Вигерса широко распространена, но и потому, что он при её написании опирался на уже существующий опыт. Есть такой институт IEEE (Institute of Electrical and Electronics Engineers), он предлагает свой набор документов, которые должны разрабатываться в процессе создания программных продуктов, и там тоже упоминается спецификация требований к ПО (SRS). Для неё есть стандарт IEEE 830, тоже, наверное, известный многим аналитикам, который до сих пор довольно активно используется.

Есть подход ГОСТовский ещё Советского союза, который сейчас распространен в России и в странах, оставшихся от СССР. Эта терминология всем вам известна и, в частности, здесь присутствует техническое задание. Здесь выделяется этап разработки Концепции и есть этап разработки Технического задания. Эти два термина — концепция и техническое задание — наиболее часто употребляются, когда мы говорим о сводных документах требований.

И есть ещё Rational Unified Process (RUP). Очень распространенный метод разработки ПО, по которому ещё лет десять назад проводилось много тренингов. Там тоже использовалась терминология, которую использовал и Вигерс в том числе: здесь мы видим снова слово «Vision», здесь та самая спецификация юзкейсов (вариантов использования), и здесь же присутствует SRS.

То есть, ещё раз повторим, есть такие документы: Концепция или Vision, Спецификация пользовательских требований, Техническое задание и SRS. Это наиболее часто используемые названия сводных документов требований. Но того, что таких стандартов несколько, возникает иногда некоторая путаница в том, что же за этими документами стоит.

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

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

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

Если мы следуем нашим стандартам (ГОСТам), то по Концепция — это совсем другой документ. Это фактически результат работы. Надо понимать, что ГОСТ разрабатывался в советское время, в эпоху ещё совсем больших машин. Ни о каком интернете тогда речь не шла, а персональные компьютеры представлялись сказкой.

И поэтому, чтобы разработать новую систему, применялись довольно тяжеловесные и дорогостоящие методы. А Концепция должна была представить несколько вариантов автоматизированной системы, которую мы можем создать. В ней представлены очень высокоуровневые бизнес-требования, которые совершенно не пересекаются с терминологией «Vision» Вигерса.

Это надо понимать: если вам приходится работать по ГОСТам, то Концепция ГОСТ и Vision — это совершенно разные документы. То есть Концепция по ГОСТу должна представить разные варианты создания системы для выбора, и в том числе может использоваться для принятия решения о том, что продукт разрабатываться не будет. Это этап, который проводится до начала проекта.