[БЕЗ ЗВУКА] Отдельная группа требований, требующая специального внимания — это требования пользователей, user requirements. Требования пользователей описывают цели и задачи, которые пользователям позволяет решать система. К отличным способам представления этого вида требований относятся различные варианты использования, сценарии использования, таблицы «событие — отклик» и так далее. Таким образом указывается, что клиенты смогут делать с помощью системы. Чтобы собрать требования пользователей и других заинтересованных лиц, надо сначала определить, кто ими является. В соответствии со стандартом 42010 заинтересованные стороны какой-либо системы — это стороны, имеющие интерес в этой системе. Интересы заинтересованных сторон выражены как польза или проблема. Заинтересованные стороны формируют для системы различные цели. Цели являются одним из видов выражения интересов. Стандарт приводит и примерный перечень заинтересованных сторон. Во-первых, это пользователи системы, во-вторых, ее операторы. Далее заказчики, владельцы системы, поставщики системы, разработчики системы. Те, кто обеспечивают реализацию системы, и те, кто ее кто ее сопровождают. Процесс выявления заинтересованных лиц фактически создает реестр заинтересованных лиц как документ проекта. В процессе сбора требований заинтересованных сторон следует разделять требования и ожидания, которые требуется еще формализовать и также представить в виде требований. Вот некоторые примеры потребностей разных заинтересованных лиц. К примеру, конечный пользователь заинтересован в интуитивно понятном и корректном поведении, правильной производительности, надежности, удобстве использования, доступности и безопасности. Системный администратор заинтересован в интуитивном понятном поведении системы, управлении, инструментах мониторинга. Специалист по маркетингу заинтересован в конкурентоспособных функциях, времени до выхода программы на рынок, позиционировании среди других продуктов и ее стоимости. Клиент заинтересован в цене, стабильности и возможности планировать. Разработчик заинтересован в понятных требованиях и простом и не противоречивом принципе проектирования. Руководитель проекта заинтересован в предсказуемости хода проектирования, планирования продуктивном использовании ресурсов и бюджета. А специалист по сопровождению заинтересован в понятном и не противоречивом, документируемом принципе проекта, а также в легкости, с которой можно вносить изменения. Видно, что многие пункты из списка интересов являются нефункциональными по характеру, то есть они не влияют на функциональность системы, например, интерес по отношению к цене и планированию. Но именно на основе их требований часто формулируются свойства и ограничения системы. Тут важно не путать требования пользователей с системными требованиями. При этом отдельную группу будут составлять пользователи, непосредственно взаимодействующие с системой. Ведь на основе именно их требований должны формироваться архитектура пользовательских взаимодействий и дизайн интерфейсов. К примеру, требования к формату экрана, компоновка страницы, содержание любых отчетов или меню, наличие программируемых функциональных клавиш и тому подобное. Но, отбирая частные требования, важно держать в голове основной принцип: какую именно деятельности мы проектируем? Поставленная цель деятельности и, соответственно, реализация проекта часто приводит не к тому результату, который планировался, из-за ошибки в выборе точке зрения на проект. Из-за этого достижение декларируемой цели не удовлетворяет реальной потребности либо удовлетворяет ее не полностью или не тем способом, который ожидался. Вспомним историю с золотой рыбкой, где старуха желала получить достойный выкуп, но потребовала корыто. Поэтому всегда важно понимать, о какой и чьей именно деятельности идет речь и, соответственно, какие требования должны учитываться и как, поскольку процесс деятельности является рекурсивным. Система, осуществляющая деятельность, всегда сама является средством осуществления чьей-то деятельности. К примеру, пусть его проблема, что жителям отдаленного региона трудно добраться до центра города. Способ решения этой проблемы будет совершенно разным в зависимости от того, кто именно декларирует так проблему. И если проектируемая деятельность — по удовлетворению потребности попасть в центр, то она будет совершенно разной, к примеру, для разных категорий жителей района. Она будет другой для предпринимателя, который увидит в этом возможность заработка, или же для администрации района, желающей снизить социальную напряженность. Или для транспортной компании, которой будет предложено организовать перевозки. Представим, что на эту проблему обратил внимание предприниматель. И, обнаружив ее, он начинает удовлетворять ее для получения прибыли. При анализе способов решения он приходит к выводу, что оптимальным для него, для предпринимателя, способом решения, будет использование системы мониторинга и оптимизации движения автобусов. А средством решения, соответственно, должно стать приложение интернета вещей, выполняющее функцию мониторинга и оптимизации движения. Далее, опять же продолжая свою деятельность, имеющую целью получение прибыли, предприниматель обращается к проектной команде, которая, как он ожидает, может предоставить ему соответствующее средство. Для проектной команды целью деятельности становится удовлетворение потребности заказчика, для чего ей необходимо разработать систему мониторинга и оптимизации пассажирских перевозок. В свою очередь, целью деятельности приложения становится достижение заданных параметров эффективности перевозок, к примеру, минимизация времени ожидания автобусов, увеличение их заполняемости, снижение затрат на эксплуатацию и тому подобное. Важно, что заданные показатели будут совсем другие, если заказчиком системы станет, к примеру, городская администрация, у которой цели деятельности совершенно иные, чем у предпринимателя. Проблемой может стать и несоответствие заявляемых и фактических целей проекта, несоответствие между позициями по отношению к проекту реального и номинального заказчиков. Например, в описываемом выше примере проект инициирует городская администрация, но договор заказчика заключает сторонняя компания, выигравшая конкурс. При этом финансирование проекта идет от внешнего спонсора. Проект на контроле у мэра, но заказчиком определен сотрудник, ответственный за реализацию проекта. Кроме того, решение о финансировании разработки остается за спонсором. И вот на чьи именно требования: мэра, заказчика спонсора, следует ориентироваться разработчикам? А как быть, если администрация декларирует целью проекта удобство жителей, и именно эти требования фигурируют в техническом задании, а по факту известно, что финансирование проекта будет зависеть от достигнутых благодаря проекту рейтингов перед очередными выборами.
