Требования к программному обеспечению — совокупность запросов/утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе проработки (анализа и синтеза) задания на разработку/модернизацию программного обеспечения (ПО).
Требования могут выражаться в виде текстовых утверждений и графических моделей.
В классическом техническом подходе совокупность требований используется на стадии проектирования ПО. Требования также используются в процессе проверки ПО, так как тесты основываются на требованиях.
Этапу разработки требований может предшествовать технико-экономическое обоснование или концептуальная фаза анализа проекта. Фаза разработки требований может быть разбита на выявление требований (сбор, понимание, рассмотрение и выяснение потребностей заинтересованных лиц), анализ (проверка целостности и законченности), спецификация (документирование требований – синтез текстовых и графических моделей) и проверка правильности.
17/48 — Методы выявления требований часть 1. Курс Бизнес-анализ в IT.
Источник: wiki2.org
Классификация требований/Что представляет собой каждый вид требования.
Transition Requirements в BABOK — это требования, которые определяют переход от текущего состояния бизнеса к желаемому состоянию в будущем. Они описывают изменения, которые необходимо внести в текущую организацию, процессы и системы, чтобы достичь желаемых результатов. Это может включать в себя такие элементы, как изменение процессов, внедрение новых технологий, внедрение изменений в организационную структуру и т.д. Они важны для того, чтобы гарантировать, что изменения, внесенные в систему, будут эффективными и выполнятся в соответствии с желаемыми результатами.
Пользовательские требования
Функциональные требования
Список требований
Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?
Вопрос, что считать требованием к ПО, является сугубо дискуссионным. Но так или иначе нам с вами необходима отправная точка для изучения темы, поэтому обратимся к уже устоявшимся определениям:
Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).
Требования к ПО — совокупность утверждений относительно атрибутов, свойств или качеств программной системы , подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований (Википедия).
Из определений можно выделить следующие пункты, которые относятся к требованиям:
2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)
- Спецификация — документ, устанавливающий требования.
- Реализация — интерпретация требований в виде разработанной системы (одни и те же требования можно реализовать различными способами).
- Описание поведения системы (то, как система должна работать при различных входных условиях).
- Описание свойств / атрибутов / качеств системы.
Как видно выше, устоявшиеся термины не отражают всю полноту понятия «требование к ПО», поэтому также стоит отметить следующее: требования охватывают как видение пользователя, так и внешнее поведение системы, а также представление разработчика о некоторых внутренних характеристиках. Они включают как поведение системы в определенных условиях, так и свойства, которые делают систему полезной и удовлетворяющей конечных пользователей.
Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.
Уровни и типы требований
Требования к ПО состоят из трех уровней:
- Бизнес-требования.
- Пользовательские требования.
- Функциональные требования.
Отдельно вне иерархии выделяют нефункциональные требования. Они так или иначе всегда представлены на всех уровнях требований и прямо или косвенно влияют также на все из них. Далее подробнее разберем каждый уровень требований отдельно.
Бизнес-требования BRQ
Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.
Бизнес-требования — это верхний уровень абстракции требований к системе. Они не относятся напрямую к реализации проекта, а в первую очередь отражают цели бизнеса, абстрагированные от реализации системы. В конечном итоге бизнес-требования формируют документ концепции и границ.
Если кратко, документ содержит определение следующих понятий:
- Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
- Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
- Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
- Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.
Источники бизнес-требований (где искать?):
- Внутренняя документация компании (положения, инструкции, приказы).
- Документация по предметной области (профильные литература и статьи, исследования).
- Нормативная документация (законы и иные правовые акты, государственные стандарты).
- Продукты конкурентов.
Стейкхолдеры (у кого спрашивать?):
- Инициатор проекта.
- Руководитель проекта (менеджер проекта).
- Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
- Бизнес-аналитик.
Пользовательские требования URQ
Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).
Пользовательские требования определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе (Википедия).
Источники пользовательских требований требований (где искать?):
- Анализ и декомпозиция бизнес-требований.
- Описание бизнес-процессов.
- Артефакты бизнес-процессов:
- документы входные/выходные,
- стандарты,
- регламенты,
- обрабатываемые данные,
- иная информация, используемая и/или производимая в бизнес-процессе.
- Отраслевые стандарты.
- Реализованные проекты, проекты конкурентов.
Функциональные требования FRQ
Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.
Функциональные требования определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований.
Функциональные требования самые низкоуровневые.
Источники требований (где искать?):
— Анализ пользовательских требований.
— Таски.
— Прототипы интерфейса (мокапы).
— Отраслевые стандарты.
— Внешние системы и документация к ним (интеграции).
Нефункциональные требования NFRQ
Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
Источник: teletype.in
Анализ бизнес-требований
Любые новые действия, продукты или проекты создаются в ответ на потребности бизнеса. Тем не менее, мы часто оказываемся в ситуациях, когда несмотря на огромные затраты времени и ресурсов, прослеживается несоответствие результата разработок реальным потребностям клиентов.
Жаловалась ли когда-нибудь клиентка на то, что ей доставили не то, что она заказала? Изменил ли кто-нибудь из заинтересованных лиц свое мнение о результатах, когда вы были на полпути к завершению проекта? Встречались ли вы с противоречивыми требованиями от нескольких клиентов? И выдвигались ли вам когда-нибудь новые требования сразу после того, как создание продукта было фактически завершено?
Целенаправленный и подробный анализ бизнес-требований может помочь избежать подобных проблем. Это процесс обнаружения, анализа, определения и документирования требований, связанных с конкретной бизнес-целью. И с его помощью вы четко и точно определяете масштаб проекта, чтобы оценить сроки и ресурсы, необходимые для его завершения.
Помните, чтобы получить ожидаемый результат, нужно точно определить его — достичь этой цели поможет глубокий анализ бизнес-требований. Иными словами, чтобы лучше понять бизнес-потребности, нужно разделить их на подробные, конкретные требования, которые всех устраивают. Более того, обычно гораздо быстрее и дешевле устранить проблему или недоразумение на этапе анализа, чем при поставке «готового продукта».
Во многих компаниях уже разработаны свои процедуры и методологии для проведения анализа бизнес-требований, которые оптимизированы для использования в данной организации или отрасли. Если таковые существуют, используйте их! Тем не менее, будет полезно учесть и информацию, которую мы расскажем вам далее.
Как определить бизнес-требования
Руководство по проведению анализа бизнес-требований состоит из пяти этапов.
1. Определение ключевых заинтересованных сторон
Определите ключевых людей, которые будут затронуты проектом. Сначала уточните, кто именно спонсирует проект. Им может быть внутренний или внешний клиент. В любом случае важно знать, за кем решающее слово в отношении того, что будет включено в рамки проекта, а что нет.
Затем определите, кто будет использовать данное решение, продукт или услугу, то есть ваших конечных пользователей. Поскольку ваш проект предназначен для удовлетворения их потребностей, необходимо учитывать их пожелания.
Убедитесь, что вы составили полный список заинтересованных сторон: помните, что все конечные потребители продукта или услуги могут находиться в одном подразделении или отделе, или же они могут быть распределены по разным отделам или уровням вашей организации. Наша статья об анализе заинтересованных сторон поможет вам определить их.
2. Учет требований заинтересованных сторон
Узнайте требования всех ключевых заинтересованных сторон к новым продуктам или услугам. Каковы их ожидания и пожелания?
Помните, что каждый человек рассматривает проект со своей индивидуальной точки зрения. Вы должны принять эти различные точки зрения и собрать соответствующие требования, чтобы составить полную картину результата проекта.
Общаясь с заинтересованными сторонами, четко представляйте, в чем заключается основной объем проекта, и проводите свои обсуждения в рамках этого. В противном случае у конечных пользователей может возникнуть соблазн внести все виды функциональности, которые ваш проект и не предполагал предоставлять. Если пользователи будут подразумевать такие требования, они будут разочарованы, не обнаружив их реализации в окончательном продукте.
Для понимания и учета этих требований можно использовать четыре следующих метода.
Проведите личную беседу с каждым заинтересованным лицом или конечным пользователем. Это позволяет понять конкретные взгляды и потребности каждого из них.
Они помогут вам понять, как происходит обмен информацией между различными подразделениями или отделами, и обеспечить бесперебойное управление передачей данных.
Во время групповых семинаров и фокус-групп задавайте вопрос «Почему?» для каждого требования. Это поможет устранить неприемлемые или излишние требования и составить список наиболее важных задач.
Этот метод-сценарий позволяет вам шаг за шагом пройти через всю систему или процесс в качестве пользователя, а также понять, как будет работать система или сервис. Это очень удобный метод сбора информации о функциональных требованиях, но вам может потребоваться несколько «вариантов использования», чтобы оценить функциональность всей системы.
Возможно уже существуют варианты использования аналогичных систем или служб. Их можно взять в качестве отправной точки для разработки собственного варианта использования.
Создайте макет или модель системы или продукта, чтобы пользователи получили представление о том, как будет выглядеть конечный результат. С помощью прототипа пользователи смогут получить ответы на свои вопросы относительно практического применения, а также выявить любые несоответствия и проблемы.
Вы можете использовать любые из вышеперечисленных методов для сбора максимального количества требований. Например, получив после проведения интервью полный список требований, вы сможете создать прототип системы или продукта.
3. Классификация требований
Чтобы упростить анализ, сгруппируйте требования по следующим четырем категориям:
- Функциональные требования — определяют, как продукт/услуга/решение должны функционировать с точки зрения конечного пользователя. Они описывают характеристики и функции, с которыми потребитель будет взаимодействовать непосредственно.
- Эксплуатационные требования — определяют операции, которые должны выполняться в фоновом режиме, чтобы продукт или процесс функционировали в течение определенного периода времени.
- Технические требования — определяют технические вопросы, которые необходимо учитывать для успешного внедрения процесса или создания продукта.
- Переходные требования — это шаги, необходимые для бесперебойного внедрения нового продукта или процесса.
4. Интерпретация и регистрация требований
После того как вы собрали и классифицировали все требования, определите, какие из них реально достижимы и как система или продукт могут им соответствовать.
Чтобы интерпретировать требования, выполните следующие действия:
- Точно определите требования. Убедитесь, что требования отвечают следующим условиям:
- Не подразумевают двусмысленности и не расплывчаты.
- Четко сформулированы.
- Достаточно подробны (перерасходы и проблемы проекта обычно возникают из-за появления неизвестных факторов, которые не были идентифицированы или достаточно хорошо проанализированы).
- Связаны с потребностями бизнеса.
- Точно определяют рабочую систему или дизайн продукта.
- Определите приоритеты требований. Хотя все требования важны, некоторые из них имеют приоритет над остальными, а бюджеты обычно ограничены. Поэтому определите, какие требования относятся к действительно важным, а какие к «дополнительным».
- Проанализируйте влияние изменений. Проведите импакт-анализ, чтобы убедиться в полном понимании последствий, которые ваш проект будет иметь для существующих процессов, продуктов и людей.
- Разрешите конфликты. Обсудите с ключевыми заинтересованными сторонами и разрешите любые конфликты требований. Для этого может пригодиться анализ сценариев, поскольку он позволит всем вовлеченным лицам понять, как предлагаемый проект будет работать в различных возможных «будущих ипостасях».
- Проанализируйте исполнимость. Определите, насколько надежным и доступным в использовании будет новый продукт или система. Детальный анализ может помочь выявить любые серьезные проблемы.
По окончании анализа представьте свои ключевые выводы и подробный отчет о потребностях бизнеса в письменном виде.
Распространите этот документ с указанием реалистичного срока завершения проекта среди ключевых заинтересованных сторон, конечных пользователей и групп разработчиков, чтобы получить обратную связь. Этот отчет будет способствовать разрешению любых затянувшихся конфликтов заинтересованных сторон и может стать частью «контракта» или соглашения между вами и всеми заинтересованными сторонами.
5. Получение официального подтверждения
Наконец, получите подписанное ключевыми заинтересованными сторонами или представителями их групп соглашение, в котором отмечено, что представленные требования точно отражают их потребности. Это официальное обязательство сыграет важную роль в обеспечении того, чтобы в дальнейшем не пострадать от «расползания масштаба проекта».
Источник: dialog.guide