Управление требованиями : Детализация продукта

Детализация продукта

Раскрытие черного ящика

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

ВАЖНО! Это опять-таки не решение в понимании архитектуры и дизайна. Тут может возникнуть вопрос – как отличить “что” от “как”. Дело в том, что смысл вопроса меняется от шага к шагу. Например:

Шаг 1. “Что” это реальные проблемы stakeholder’ов, “как (мы хотим их решить)” – это требования, выраженные пользователями.

Шаг 2. “Что” – это требования, “как (как мы их решим)” – это набор features продукта.

Шаг 3. “Что” – это набор features, “как (как мы опознаем (по каким измеримым признакам?) это наше решение)” – это детальные спецификации.

Шаг 4. “Что” – детальные спецификации, “как #1 (мы это сделаем)?” – design, “как #2 (мы это проверим)?” – test и так далее.

FURPS

FURPS это сокращение, принятое в RUP для обозначения детальных требований. Расшифровка это Functionally, Usability, Reliability, Performance, Supportability.

Functionality - Услуги	Каким способом будет использоваться продукт, какие действия и как он должен осуществлять.
Usability - Удобство пользования	Эстетика, логичность, последовательность, защита от дурака, документирование.
Reliability - Надежность	Частота/критичность сбоев и защита от них, требования к восстановлению, предсказуемость поведения, точность.
Performance - Производительность	Производительность вычислений, использование ресурсов, пропускная способность, время ответа.
Supportability - Удобство эксплуатации	Диагностика, адаптация к изменяющимся требованиям, расширяемость, совместимость, многоязычность, конфигурирование, трудоемкость установки и поддержки.

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

Функциональные требования могут быть описаны набором вариантов использования (точка входа + алгоритм) или декларацией (продукт будет делать…). Выбор одного или другого подхода неоднозначен и зависит от:

• Самого продукта, например
  • для компилятора удобнее использовать декларативный подход с AST или BNF нотацией;
  • для продукта, реализующего бизнес-процесс пользователя – use-cases (поскольку есть четко выраженные процессы).
  • Для какого-нибудь информационного табло – модель данных и правила показа.
• Заказчика продукта (что удобнее читать и понимать).

Декларирование требований

Если требование не является use-case’ом, то оно формулируется в виде декларации: “Продукт должен” (product shall). Требование не должно быть чрезмерно объемным. Как правило, достаточно 3-5 предложений для формулирования требований.

Декларативные требования, относящиеся к продукту в целом, помещаются в Supplementary Specification. Требования, относящиеся к конкретному варианту использования (например, время ответа ограничено только для одного use-case) могут быть помещены как в Supplementary specification, так и в спецификацию конкретного варианта использования.

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

Usability

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

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

Reliability

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

• Доступность системы;
• Регламент восстановления при сбоях, требования к сохранению информации при сбоях;
• Защита от неверных данных, защита от помех;
• Время наработки на отказ…

Performance

Уже рассмотрели

Supportability

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

Design Constraints

• Equipment;
• Operating Systems;
• Databases;
• Protocols;
• Compatibility;
• Standards (все, от мировых до корпоративных).

Важно, что все декларативные требования должны быть:

• Наблюдаемыми;
• Измеримыми;

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

Детализация Use cases

В данный момент мы имеем:

• Выделенных и кратко описанных актёров и use-cases;
• Базовые и альтернативные потоки для use-cases, описанные на высоком уровне (с точки зрения пользователя).

Теперь следует детализовать варианты использования. Детализация включает в себя:

• Более подробное описание flows;
• Структуризация;
• Выявление дополнительных свойств use-cases.

Детали процессов

Все потоки событий уточняются, так что бы подробно и точно описать:

• Что делает пользователь;
• Что делает продукт в качестве реакции на действия пользователя;
• Какой информацией обмениваются пользователь и продукт.

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

Детальный поток событий должен быть уже спецификацией КАК должен работать продукт (до этого было: как пользователь работает с продуктом).

В зависимости от стиля разработки, в этот момент уже может быть специфицирован пользовательский интерфейс. Иногда это делается сразу, иногда – уже после архитектурного дизайна, специальным UI engineer.

Общие правила описания:

• Каждый шаг во flow имеет четкого исполнителя.
• Каждый шаг выражает четкое действие.
• Каждый шаг имеет четко описанный вход и выход.
• Каждый шаг остаётся наблюдаемым поведением продукта. По другому, этот пункт можно сформулировать как: В use-case описывается только то, что существует независимо от продукта, в самой предметной области.

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

• Является ли flow исключительным (exceptional), т.е., приводит ли к ненормальному завершению операции.
• Является ли flow типичным или редко используемым.

Стоит учитывать, что альтернативные flows могут быть как четко привязаны к конкретному шагу другого flow, так и быть “generic”, т.е. случиться в любом месте основного или альтернативного flow. Кроме привязки к шагу, альтернативные flow могут содержать условие выполнения или условие повторения.

При описании процессов могут (и должны) использоваться диаграммы активности (UML activity, ГОСТ 19.003/IDEF1, IDEF0, ARIS, Sequence). Если необходимо – рассказать о каждой.

Структуризация внутри use-cases и самих use-cases

При описании деятельности возникают следующие ситуации:

• Выполнение различных вариантов по условию;
• Повторяющие в разных местах цепочки действий;
• Многократно выполняемые действия.

Важно! В отличие от альтернативных потоков (разных путей выполнения именно процесса) здесь речь идет уже о единичных действиях.

Например: Продукт “Жена”, Use-case “Приготовить завтрак”.

Happy-day scenario: жена готовит свежий завтрак по кулинарной книге.

Альтернатива 1: разогревается вчерашний ужин.

Альтернатива 2: разогревается полуфабрикат.

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

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

В случае, если альтернатива или повтор небольшой (в пределах одного действия), можно использовать условные конструкции типа IF … THEN … ELSE … или REPEAT … WHILE/UNTIL ….

Если sub-flow используется в разных use-cases, либо use-cases имеют одинаковые flows, такие могут быть оформлены как служебные use-case. Между “нормальными” use-case и такими, служебными, use-case могут быть отношения:

• includes (служебный use-case неотъемлемая часть процесса)

Используется для сокрытия несущественных деталей и переиспользования части процесса.

• extends (служебный use-case может использоваться в процессе)

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

• generalization (служебный use-case описывает поведение в общем, остальные уточняют конкретный flows и шаги исходного use-case).

Как и в случае с объектами, generalized use-case может быть как абстрактным (т.е. он сам по себе не может быть выполнен), так и конкретным (может быть выполнен сам по себе). Так же могут быть обобщены и actors, в случае если некоторый набор актёров имеет одинаковое поведение.

Служебный use-case может не требовать законченности процесса (т.е. ценности результата для конечного пользователя).

Использование sub-flows и служебных use-cases позволяют:

• Упростить описание (но усложнить чтение) модели. Именно поэтому мы используем этот приём уже ПОСЛЕ того, как согласовали с заказчиками.
• Выявить общее поведение, тем самым оптимизировать проектирование и разработку.
• Переиспользовать use-cases не только внутри проекта, но и между проектами.
• Изолировать повторяющиеся операции и обеспечить синхронизацию их изменений.

Недостатки структуризации:

• Использует понятия ООА, что усложняет чтение неподготовленным читателем;
• Усложняет поддержку модели;
• Требует больших затрат времени для чтения от reviewer-ов, разработчиков и тестеров;

Выявление pre и post условий

Use-case не всегда может быть выполнен в любой момент или в любом состоянии системы. Pre-condition – это набор условий который должны быть истинны для того, что бы use-case мог быть использован. Важно, что pre-condition это НЕ есть событие, которое инициирует use-case.

Например, TS: “Open Position” pre-condition is “User must be logged in, an offer must be chosen in the offer list”. При этом изначальное открытие таблиц НЕ является use-cases с pre-condition “User just logged in”, а является часть процесса “Log-in”. Pre-condition относится ТОЛЬКО к продукту, но ни к чем снаружи от него.

Например, “пользователь должен иметь корректный login/пароль НЕ является предусловием. Pre-condition может так же задаваться для альтернативного flow.

Post-condition это состояние системы или условие, которое гарантированно будет выполняться при успешном завершении use-case. (Login->User is loggied in).

Связывание use-cases через pre и post условия позволяет указывать возможные последовательности выполнения use-cases. При этом важно, что use-cases НЕ сообщаются напрямую, а только могут изменять состояние системы (т.е. нельзя сказать “Use case: log in должен быть успешно выполнен”).

Формальное описание use-case

Каждый use-case, как говорилось ранее, описывается отдельным документом. Каждый use-case должен иметь уникальный номер. Каждый flow в use-case должен иметь уникальный номер. Каждый шаг в flow должен иметь уникальный номер. Так, что бы при ссылках, можно было указывать как номер, так и название, например: UC12. Request For Quote, Sub-Flow 2, Rejecting Quote, Step 3. Подробное описание use-case включает в себя:

• Название use-case.
• Актеров, которые могут его использовать и цели актеров.
• Вход use-case (данные и ограничения на значения) которые уже должны быть у актёра для начала use-case.
• Pre-условия (или context) – состояние продукта в котором он должен находится что бы use-case мог быть выполнен.
• Post-условия – состояние продукта в котором он будет находится после того, как use-case будет выполнен.
• Выход use-case (данные и критерии их проверки) которые будет получены актёров в результате исполнения use-cases.
• Basic (happy-day) flow.
• Набор альтеранивных flow (regular, rare, exception) и sub-flows.
• Сценарии.
• Supplementary requirements.