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

SECR 2018
Константин Валеев
Начальник отдела, Рестрим

Я расскажу про то, как управлять практиками спецификации требований — инструментами и нотациями для фиксации требований в виде текстов и схем, понятных разным участникам разработки; как выбрать из многообразия инструментов подходящие под ваш проект. Расскажу, в чём нам здесь может помочь SEMAT Essence, а в чём нет.

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

Transcript

1. Практики спецификации требований Константин Валеев, октябрь 2018
2. Обо мне • Работал с разными проектами: и в маленьких стартапах и в больших компаниях • Руковожу отделом аналитиков и техписателей в «Рестриме» — софтверной дочке «Ростелекома» • Пишу диссертацию по инженерии требований
3. О чём мой доклад • Про спецификацию требований • Какие есть инструменты для этого • Как их выбрать и что мешает это сделать
4. Что мы понимаем под требованиями
5. Свойство, которое должно быть реализовано чем-либо, чтобы решить какую-то проблему в реальном мире — SWEBoK
6. 1. Свойство или способность, необходимая заинтересованному лицу для решения проблемы или достижения цели. 2. Свойство или способность, которые должны быть выполнены или которыми должно обладать решение или его компонент для удовлетворения условий контракта, стандарта, спецификации или других официальных документов. — BABoK
7. Что угодно, что определяет проектные решения — Brian Lawrence
8. Утверждение о потребности или цели клиента, или свойства и способности, которые продукт должен иметь для удовлетворения такой потребности или цели — Karl Wiegers and Joy Beatty
9. Описание того, как должна себя вести система, или описание свойства или качества системы — Ian Sommerville and Pete Sawyer
10. Что программная система должна делать для решения проблемы и удовлетворения заинтересованных сторон — OMG Essence
11. Архитектурное проектирование — это то место, где процесс требований перекрывается с разработкой программного обеспечения или систем и иллюстрирует, насколько невозможно полностью разделить эти две задачи. — SWEBoK
12. Модель требований
13. WRSPM-модель • W — описание реального мира (предметная область) • R — требования • S — спецификации системы • P — программа работающая на аппаратном обеспечении (машине) • M — машина
14. Что специфицируют
15. • Архитектурные требования • Бизнес-требования • Требования пользователей (заинтересованных сторон) • Функциональные требования • Требования к качеству работу (нефункциональные) • Требования к внедрению — BABOK
16. • Функциональность • Удобство использования (UX) • Надежность • Производительность • Возможность поддержки • Архитектурные требования • Требования к реализации • Требования к интерфейсам • Физические требования — FURPS+
17. • Бизнес-требования • Функциональные требования • Требования заинтересованных сторон • Нефункциональные требования • Требования к внедрению — Enterprise Architect User Guide
18. Представления модели (views)
24. Модель меняется со временем
25. Как выбрать способ спецификации? • Представлений много • Способов спецификаций много • Часть из них взаимозаменяемая, часть может быть связана • Выбор зависит от многих факторов
26. А как выбирают? • По интуиции • Вместе с методологией • По привычке • Модные • Популярные
27. Может быть есть осознанный подход?
28. SEMAT ESSENCE Essense of Software Engineering Method and Theory
32. Альфа требований Связана с остальными альфами Имеет своё состояние Использует практики
33. Практика — это повторяемый подход для выполнения чего- либо с определенной целью — Introduction to SEMAT
34. Некоторые практики спецификации Бизнес-требования Пользовательские и требования к поведению Предметная область Технические требования и архитектура BPMN CJM ERD Archimate CMMN UML RDF Robustness Diagram BMM JTBD OWL UML EPC User Story ORM SysML IDEF0 BDD (Gherkin) Domain Model (UML) DFD DMN Use Case IDEF4/5 ADR DEMO Use Case (2.0) BORO TOGAF Business Rules Task Description API-спецификации Value Stream Map Прототипы и User flow Bussiness Model Canvas
35. SEMAT про статус альф, а не про их параметры
36. А выбор практики во многом зависит от параметров проекта — его альф, а не от их статуса
37. Некоторые параметры Стейкхолдеры Система Команда Методика работы Внешние/ внутреннее Сложность Размер Методология Плотность коммуникации Тип Плотность коммуникаций Выбранные практики Вовлеченность Предметная область Квалификация ...
38. Совместное использование практик • CMMN ⬌ BPMN ⬌ Use Case • User Story ⬌ Use Case • Use Case 2.0 ⬌ User Story • ERD ⬌ Макеты ⬌ Robustness Diagram ⬌ Use Case • ERD ⬌ Archimate ⬌ Use Case ⬌ BPMN
39. Диаграммы надежности
40. Archimate
41. А можно всех посмотреть?
42. Нет библиотеки практик • С описанием • свойствами, • применимостью, • ограничениями, • рекомендациям по связности, • применимостью в разных методиках, • подводными камнями.
43. Пока нет? practicelibrary.ivarjacobson.com
44. Заведите свою, хотя бы страничку в вики
45. Отслеживайте изменения и меняйте практики
46. Потому что проект меняется
47. CJM User Story ERD UI макеты
48. CJM User Story ERD UI макеты BPMN UML
49. CJM User Story ERD UI макеты Use Case BPMN Robustness Diagram UML DFD
50. Archimate Sys ML CJM User Story ERD UI макеты Use Case BPMN Robustness Diagram UML DFD
51. Контролируйте
52. Договаривайтесь • Бизнес-аналитик • Системный аналитик • Продуктовый аналитик • Архитектор • Менеджер продукта
53. Договаривайтесь • Единые правила • Единые термины (SEMAT) • Согласованные практики • Коммуникация • Автоматизация и связность
54. Отслеживайте • Рефлексия боли • Ретроспективы • Кайдзен • Смотрите по сторонам
55. Не только про спецификации
56. Константин Валеев kvaleev@gmail.com @kvaleev (https://t.me/kvaleev)