Комплексный и надежный процесс спецификации требований - Википедия - Comprehensive & Robust Requirements Specification Process
 | Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) (Узнайте, как и когда удалить этот шаблон сообщения)
|
В Комплексный и надежный процесс спецификации требований (CRRSP), или же CRRSP (произносится хрустящий), представляет собой методологию сбора, определения и проверки требования к программному обеспечению. CRRSP - это не пошаговый ограничительный процесс, а адаптируемая структура, предназначенная для настройки командами бизнес-анализа, которые выбирают элементы процесса, соответствующие их потребностям.
История
CRRSP был разработан в 2008 году старшим бизнес-аналитиком Барбарой Дэвис после многих лет исследований и усовершенствований, основанных на практическом опыте работы старшим бизнес-аналитиком и директором по практике Центра передового опыта бизнес-аналитиков с такими организациями, как UST Global и Safeway.
Связь с другими методологиями
Подход CRRSP к требованиям к программному обеспечению позволяет применять приложения с большинством типов проектных методологий и является гибкой и адаптируемой отправной точкой, в которой можно применять методологию. CRRSP отличается от других методологий, таких как Водопад, РАД, Гибкий, и RUP потому что это, в частности, методология определения и проверки требований в контексте более крупного жизненного цикла проекта, в то время как другие являются методологиями проекта, которые определяют сам общий жизненный цикл проекта.
Одним из основных факторов в CRRSP является то, что он развивает требования через требования высокого, среднего и низкого уровня за счет все более глубокого погружения в обеспечение требований.
Этапы
Ключевыми этапами методологии требований CRRSP являются исследования и выявление, анализ, разработка и спецификация и проверка.[1] Он характеризуется подробными этапами, инструментами и методами проверки, а также уникальными результатами анализа и продуктами для отслеживания.
Исследования и выявление
Целью этапа исследования и выявления является понимание и исследование бизнес-драйверов, целей и задач, артефактов проектов, созданных на сегодняшний день, и создание рабочего процесса, который поможет проиллюстрировать текущее состояние и желаемое состояние в будущем. В конечном итоге он определяет требования среднего уровня к проекту.
Анализ
При анализе требований среднего уровня аналитик использует оценку пробелов, более детальную форму анализа пробелов, а также таблицы причин и следствий или решений для описания сценариев, в дальнейшем преобразовывая требования высокого уровня в требования среднего уровня.
Разработка и спецификация
Разработка и спецификация - это этап согласованного документирования и создания документа с требованиями в формате, который в конечном итоге будет передан группам проектирования, разработки и тестирования для использования при создании их продуктов и результатов. Он генерирует уточненные бизнес-правила, уточненные схемы рабочих процессов и требования низкого уровня.
Соглашение об именах и нумерации
Методология CRRSP диктует строгие правила именования и нумерации требований в рамках проекта и продуктов в целом. Он следует аналогичной логике и логике присвоения имен ураганам и торнадо в том смысле, что требованию присваивается исключительный номер, который остается его собственным, даже если статья будет утилизирована. Это обеспечивает точное отслеживание нескольких версий документации и изменений объема.
Номера присваиваются окончательному проекту перед выпуском в группы проектирования, разработки и тестирования для процесса проверки на неоднозначность. Это гарантирует, что команда BA не запутается при документировании требований. Номера присваиваются только требованиям высокого уровня; субномера назначаются требованиям среднего и низкого уровня, поскольку они являются расширениями требований высокого уровня.
Например, если в требованиях к корзине покупок в Интернете указано, что приложение должно иметь возможность рассчитывать налог для конкретного штата и / или провинции онлайн-покупателя, требование будет записано как:
1.1 Клиенты должны иметь возможность выбирать свой штат И / ИЛИ провинцию в селекторе.
Однако позже требование переформулируется, чтобы указать, что приложение должно иметь возможность рассчитывать налог для конкретного штата и / или провинции онлайн-клиента, тогда требование будет переписано как:
1.1 Требование удалено. 1.2 Штат или провинция из профиля клиента будет использоваться для расчета налогов на покупку.
Проверка
Валидация использует комбинацию методов неоднозначности, полученных в результате тестирования на основе требований.[2] и логическое моделирование.[3] Эти методы включают журнал неоднозначности, анализ неоднозначности и пошаговые инструкции по устранению неоднозначности с участием групп проектирования, разработки и тестирования, чтобы установить ясность и полноту требований. В обзорах и пошаговых руководствах используется четкий набор критериев.[4] для проверяющих, чтобы убедиться, что информация является полной, непротиворечивой, точной и написанной на языке, который четко определяет и определяет предполагаемое функционирование нового программного обеспечения.
Сравнительный анализ
Сторонники этой методологии могут применять специальную формулу для определения эффективности действий требований путем сравнения и измерения по установленному критерию.[5] Путем сравнительного анализа действий, связанных с требованиями в рамках проекта, команда BA может лучше понять, на что тратится время, как его улучшить, и иметь возможность повысить эффективность и результативность задачи как средство улучшения проекта. Это оказалось наиболее эффективным методом для быстрого повторного согласования помеченного проекта, поскольку он дает команде понимание в ходе процесса.
Путем сравнительного анализа действий с требованиями в целом по нескольким проектам организации могут получить более подробную картину действий, связанных с требованиями, и того, где их можно улучшить. Это может указывать на возможности обучения среди команды бизнес-анализа, потребность в дополнительных ресурсах или большей поддержке со стороны руководства, но также может указывать на то, связана ли проблема с группами разработки или тестирования. Он также может предоставить достаточно доказательств, чтобы поддержать изменение общих процессов жизненного цикла.
Бизнес правила
Бизнес-правила обычно выделяются в отдельный документ со ссылками на сами требования. Условные обозначения и нумерации такие же, как и для требований, но обозначены как правила с буквой «B» перед номером.
Например, если бизнес-правило B36 для той же корзины покупок гласит, что налоги должны рассчитываться на общую сумму покупки в соответствии со ставкой налога Британской Колумбии 12%, тогда бизнес-правило будет записано как:
B36.1 Ставка налога в Британской Колумбии 12%
Если требование 1.1 ссылается на это бизнес-правило, оно будет записано как:
1.1 Заказчик должен иметь возможность выбрать свой штат И / ИЛИ провинцию в селекторе. Применимые бизнес-правила: B36
Сценарии использования
Варианты использования могут быть запущены в любой момент в процессе обработки требований и доработаны по мере выполнения требований. Их ценность заключается в добавлении уровня проверки требований для поддержки проверки на полноту. Они могут быть представлены пользователям в пошаговом руководстве, чтобы помочь проверить пошаговый процесс, через который пользователь и система будут выполнять определенные транзакции. И литературный (описательный), и диаграммный (например, UML, Мероприятия или же Swim Lane ) варианты использования подходят для этого из-за ценности, которую каждый из них может предоставить конечным пользователям.
Рекомендации
- ^ Барбара Дэвис, Requirements Networking Group, 20 января 2010 г. "«Архивная копия». Архивировано из оригинал на 2010-04-13. Получено 2010-11-23.CS1 maint: заархивированная копия как заголовок (связь)", 22 ноября 2010 г.
- ^ Джайдип, Обмен знаниями в области ИТ, 2 марта 2009 г. "[1] ", 22 ноября 2010 г.
- ^ RUSH Project, Research Utilization, 31 мая 2009 г. "[2] ", 22 ноября 2010 г.
- ^ Ричард Бендер, Bender RBT, Дата неизвестна "[3] ", 22 ноября 2010 г.
- ^ Барбара Дэвис, Requirements Networking Group, 18 января 2010 г. "«Архивная копия». Архивировано из оригинал на 2010-05-20. Получено 2010-11-23.CS1 maint: заархивированная копия как заголовок (связь)", 22 ноября 2010 г.