В предыдущем уроке мы узнали, как происходит работа над формулированием требований к проекту с точки зрения бизнес-анализа. Давайте, теперь рассмотрим, какую именно информацию мы собираем. Существует несколько подходов к классификации и описанию типов требований. И в этом уроке я предлагаю ознакомиться с ключевыми из них. В соответствии с ITIL третьей версии, это библиотека инфраструктуры информационных технологий, отдельное методологическое направление, все требования в проекте можно разделить на следующие группы: функциональные (Functional) реализуют саму бизнес-функцию; управленческие (Manageability) требования к доступным и безопасным сервисам, относятся к размещению системы, администрированию и безопасности; эргономические (Usability) — к удобству работы конечных пользователей; архитектурные (Architectural) требования к архитектуре системы; взаимодействия (Interface) — к взаимодействиям между существующими приложениями и программными средствами и новыми приложениями; сервисного уровня, (Service Level) описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком. Также в отдельную группу относятся нефункциональные требования, они не относятся непосредственно к поведению функциональности, а, скорее, описывают условия, при которых предложенное решение должно оставаться эффективным, или качества, которым решение должно удовлетворять. Другими словами, они определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы, например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации. При этом независимо от того, к какой категории относятся требования, они все должны обладать следующими характеристиками: единичность — требование описывает одну и только одну вещь; завершенность — требование полностью определено в одном месте, и вся необходимая информация присутствует; последовательность — требование не противоречит другим требованиям и полностью соответствует документации; атомарность — требование нельзя разделить на более мелкие; отслеживаемость — требование полностью или частично соответствует деловым нуждам, как заявлено заинтересованными лицами и задокументировано; актуальность — требование не стало устаревшим с течением времени; выполнимость — требование может быть реализовано в рамках проекта; недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам, оно выражает объекты и факты, а не субъективное мнение. Возможна одна и только одна его интерпретация, определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которое не может быть проигнорировано. Необязательное требование, это противоречие самому понятию требования. Проверяемость — реализованность требования может быть проверена. Для описания каждого типа требований часто подходят различные формы выражения. Так, например, эргономические и требования к интерфейсу удобнее выражать через цифровые интерактивные прототипы, а, например, функциональные и архитектурные — через диаграммы использования. Для разработки таких диаграмм обычно используют нотации UML, BPMN и ARIS. Коротко расскажу о них. UML — это унифицированный язык моделирования, Unified Modeling Language. Это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования системы. BPMN, от английского Business Process Model and Notation, нотация и модель бизнес-процессов. Это система условных обозначений (нотация) для моделирования бизнес-процессов. BPMN ориентировано как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. ARIS, акроним от английского Architecture of Integrated Information Systems. Еще одна методология и программный продукт для моделирования бизнес-процессов организации. ARIS представляет собой современный подход к структурированному описанию деятельности организации и представлению ее в виде взаимосвязанных и взаимодополняющих графических моделей, удобных для понимания и анализа. Мы не успеем углубленно изучить эти нотации и методологии, так как объема такой информации хватит на целый отдельный курс. Однако цели такого моделирования совпадают с главными задачами формулирования требований: это достигнуть единого понимания бизнес-процессов всеми сотрудниками компании, увидеть и проанализировать взаимосвязи между различными направлениями бизнеса, создать концептуальную основу для оптимизации и реинжиниринга бизнес-процессов, разработать модели для внедрения корпоративных информационных и управляющих систем, создать концептуальную основу для эффективного обучения персонала. Итак, может быть много различных требований, описанных в разных форматах. Задача agile-команды — принять участие в мероприятиях по формулированию требований и объединить их и систематизировать таким образом, чтобы каждому участнику было однозначно понятно, что именно мы планируем на уровне проекта и на уровне каждой отдельной итерации. В следующем уроке я хотел бы поговорить о том, как лучше всего взаимодействовать с пользователями при формулировании требований.
