ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 926
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Возможности элементов диаграмм деятельности по представлению
бизнес-процессов
Компонент описания бизнес-
процесса
Элемент диаграммы деятельности (Activity
diagram)
Бизнес-процесс
(как набор взаимосвязанных видов дея- тельности, преобразующих вхо- ды в выходы)
Диаграмма деятельности, основными элемен- тами которой являются элементы Action (дей- ствие), Activity edge (связи между элементами
Action, изображающие либо передаваемые объекты, либо потоки управления), Partition
(отделения).
Модель бизнес-процесса (гра- фическое, табличное, текстовое, символьное описание бизнес- процесса либо их взаимосвязан-
Набор необходимых диаграмм деятельности, являющихся различными представлениями бизнес-процесса.
158 ная совокупность)
Владелец бизнес-процесса
(должностное лицо, которое управляет выполнением бизнес- процесса и несет ответствен- ность за его результаты и эф- фективность)
Может быть изображен при помощи элемента
Partition либо указан в виде текстового описа- ния.
Потребитель бизнес-процесса
(тот, кто использует или по- требляет результаты деятельно- сти)
Может быть изображен при помощи элемента
Partition.
Дополнительные атрибуты биз- нес-процесса (например, ис- пользуемые ресурсы, испол- няющие механизмы и т.д.)
Могут быть изображены при помощи элемен- тов Partition либо указаны при помощи элемен- та Note, прикрепляемого к необходимому эле- менту диаграммы деятельности.
Классификация действий, со- ставляющих бизнес процесс, в соответствии с заданными кри- териями
Может быть выполнена при помощи элементов
Partition.
Идентификация проблемных действий
Выделение соответствующих элементов Action цветом, классификация с использованием эле- ментов Partition.
Назначение исполнителей от- дельных действий в рамках биз- нес-процесса
Может быть выполнено при помощи элемен- тов Partition.
Возможность задать «каркас» выполнения процесса
Может быть выполнено при помощи элемен- тов Partition и StructuredActivity.
Деятельность по выявлению и анализу бизнес-процессов автомати- зируемой предметной области, безусловно, несколько выбивается из набора «обязательных для выполнения» процессов в ходе проекта по разработке программной системы. Более того, анализ существующих и проектирование на его основе новых бизнес-процессов может выпол- няться и не в рамках проекта по разработке программной системы, а, например, просто в рамках проекта по повышению эффективности дея- тельности организации и/или качества выпускаемой ею продукции и/или услуг. Для целей моделирования бизнес-процессов могут быть использованы различные специализированные нотации, такие как ARIS,
BPML, IDEF0 и др., и, соответственно, инструменты, их поддерживаю- щие, а также инструменты, поддерживающие унифицированный язык моделирования UML, предназначенный, прежде всего, для разработки программных систем.
IBM Rational Software Architect (RSA) является частью IBM Software
Development Platform – набора инструментов, поддерживающих жиз- ненный цикл разработки программных систем. RSA предназначен для построения моделей разрабатываемых программных систем с использо- ванием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Этот инструмент предоставляет возможность архитекторам и аналитикам создавать раз-
159 личные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработ- ку J2EE, XML, Web-сервисов и т.д. Кроме того, Rational Software
Architect поддерживает технологию разработки, управляемой моделями
(model-driven development, MDD), позволяющую моделировать про- граммное обеспечение на различных уровнях абстракции с возможно- стью трассируемости.
Хороший пример использования RSA для целей моделирования биз- неса приведен в [16]. Однако, если возможностей RSA, как правило, достаточно для построения моделей типа As-Is, то для построения мо- делей типа As-To-Be часто их недостаточно. Дело в том, что средства
RSA позволяют построить только статическую модель существующей на предприятии схемы бизнес-процессов и не позволяют промоделиро- вать производственный (или иной) процесс в динамике. Это не позволя- ет получить количественные характеристики (показатели) отдельных бизнес-процессов и всего производственного цикла, а также выявить узкие места как в организации отдельных бизнес-процессов, так и в це- лом во всем производственном цикле.
IBM предлагает другой инструмент – WebSphere® Business Modeler
(далее – Modeler), который считается лучшим в отрасли инструментом для моделирования и имитации бизнес-процессов [8]. С помощью
Modeler бизнес-аналитики и другие пользователи (даже далекие от про- грамммирования) могут создавать бизнес-модели для документирова- ния своих процессов, а затем осуществлять их имитационное моделиро- вание, чтобы понять поведение этих процессов «в динамике». Пользова- тели могут генерировать отчеты на основе модели процесса и по ре- зультатам имитационного моделирования.
Имитация позволит оценить эффективность бизнес-процессов, со- брать статистику выполнения процессов, выявить потенциальные об- ласти для их улучшения. Имитация бизнес-процессов – это, по сути, оценка эффективности реального бизнеса в виртуальной среде.
Имеется возможность экспортирования разработанных моделей в такие среды, как WebSphere Integration Developer (Integration Developer),
WebSphere Process Server (Process Server) и IBM FileNet P8 и хранения их в таких системах как Rational® ClearCase и Rational Asset Repository.
Модели могут быть опубликованы с помощью компонента WebSphere
Business Modeler Publishing Server (Publishing Server), что позволяет ав- торизованным пользователям просматривать эти модели с помощью
Web-браузера. Эти модели могут также быть связаны с требованиями в продукте Rational RequisitePro и повторно использованы в продукте
Rational Software Architect. В версии Modeler 6.2, в дополнение к пере- численным возможностям, реализован ряд важных усовершенствований
[21].
В частности реализована новая возможность, позволяющая бизнес- пользователям развертывать свои проекты для моделирования и мони- торинга бизнес-процессов непосредственно на продуктах Process Server и WebSphere Business Monitor (Monitor). После того как проекты раз-
160 вернуты, автоматически создается новое бизнес-пространство под на- званием Test Space (пространство тестирования), в состав которого вхо- дят элементы («виджеты») для исполнения, управления и мониторинга процессов. Помимо прочего, эта новая функциональность под названи- ем design to deploy (от проектирования до развертывания) поддерживает некоторые сценарии для рабочих процессов персонала.
Пользователи продукта Integration Developer могут вносить свой вклад в отладку проектов design to deploy. Этот сценарий под названием time to value сокращает число итераций между бизнесом и ИТ, благода- ря чему ускоряется проведение процесса. ИТ-специалисты по-прежнему должны участвовать в процессе, однако объем возлагаемой на них обя- зательной работы может быть уменьшен, в результате чего увеличива- ются возможности бизнес-пользователей и сокращается время до полу- чения экономического эффекта.
После того как модель будет полностью протестирована, можно ис- пользовать функциональность design to deploy для проверки возможно- стей мониторинга модели с использованием одного из готовых шабло- нов мониторинга.
4.4.3.
Определение функциональных требований
Функциональные требования описывают сервисы, представляемые программной системой, ее поведение в определенных ситуациях, реак- цию на те или иные входные данные и действия, которые система по- зволит выполнить пользователям. Иногда сюда добавляются сведения о том, что система не должна делать.
При написании функциональных требований необходимо учитывать, что чем они будут подробнее, тем более точная оценка работ по стоимо- сти и срокам будет дана в техническом задании (ТЗ). Если на дальней- ших этапах разработки ПС не возникнет дополнений к изначально сформулированным функциональным требованиям, то эта оценка будет достаточно точной.
Функциональные требования удобно представлять в виде диаграмм вариантов использования. Вариант использования представляет собой последовательность действий, выполняемых системой, в ответ на собы- тия, инициируемые внешним объектом (действующим лицом – актором по терминологии, принятой в ряде публикаций [10]). Такие диаграммы используются в RUP-технологии разработки программных проектов
[17].
Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении сис- темы с точки зрения пользователя. В простейшем случае вариант ис- пользования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он пре- следует по отношению к разрабатываемой системе.
161
Модель варианта использования дает подробную информацию о поведении системы или приложения. Она определяет требования сис- темы в терминах требующейся функциональности (варианты использо- вания) для достижения целей или для решения проблемы, определенной пользователем, и она же описывает окружение (агенты) и отношения между вариантами использования и агентами (диаграммы вариантов использования). Модель варианта использования также включает диа- граммы вариантов и диаграммы действий, которые описывают то, как пользователи общаются с системой.
Модель вариантов использования имеет следующие достоинства: определят пользователей и границы системы; определяет системный интерфейс; удобна для общения пользователей с разработчиком; используется для написания тестов; является основой для написания пользовательской документации; хорошо вписывается в любые методы проектирования (как объект- но-ориентированные, так и структурные).
В дополнение к вариантам использования необходимо определить, как должен выглядеть пользовательский интерфейс для реализации ка- ждого варианта использования. подготовить эскизы, обсудить их с пользователями, возможно, создать прототипы и отдать их на тестиро- вание пользователям. Следует также иметь в виду, что каждый конкрет- ный пользователь работает с системой по-своему, поэтому для опреде- ления действительных вариантов использования системы необходимо досконально знать потребности всех заинтересованных пользователей, провести анализ полученной информации и систематизировать ее в дей- ствительные варианты использования системы, т.е. абстрагироваться от конкретных пользователей и исходить из бизнес-задач организации- заказчика.
Требования могут быть представлены в различных формах – от не- структурированного текста до выражений формального языка. Боль- шинство функциональных требований к системе, могут быть выражены в виде вариантов использования.
Диаграммы вариантов использования – один из видов диаграмм
UML, предназначенных для моделирования динамических аспектов систем. Это основной вид диаграмм при моделировании поведения сис- темы и требований, предъявляемых к системе. Формулирование требо- ваний к системе, по сути представляет собой составление контракта между ней и теми сущностями, которые находятся вне ее. Этот контракт декларирует, что система должна делать. Хорошая система выполняет требования точно, предсказуемо и надежно. Удобным инструментом построения диаграмм использования является IBM Rational Software
Architect (RSA) – часть IBM Software Development Platform – набора инструментов, поддерживающих жизненный цикл разработки про- граммных систем.
162
Продукт IBM Rational Software Architect предназначен для построе- ния моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моде- лей архитектуры разрабатываемого приложения. RSA объединяет в себе функции таких программных продуктов, как Rational Application
Developer, Rational Web Developer и Rational Software Modeler, тем са- мым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработ- ку J2EE, XML, Web-сервисов и т.д. Следуя принципам RUP, Rational
Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как:
Бизнес анализ и моделирование (Business modeling).
Управление требованиями (Requirements).
Анализ и проектирование (Analysis and Design).
Реализация (Implementation).
Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемости.
Правильно сформулированные функциональные требования должны обладать следующими характеристиками.
1. Полнота. Каждое требование должно полно описывать функцио- нальность, которую следует реализовать в продукте. Оно должно со- держать всю информацию, необходимую для разработчиков, чтобы им удалось создать этот фрагмент функциональности. Если данных опре- деленного рода не хватает, следует помечать такие требования (необхо- димо определить) на полях, как стандартный флаг для выделения такого места. Все пробелы в каждом фрагменте требований следует воспол- нить, прежде чем приступать к конструированию этой функции.
2. Корректность. Каждое требование должно точно описывать же- лаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например, с пожеланиями пользовате- лей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать коррект- ными. Однако основная оценка здесь – за представителями пользовате- лей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.
3. Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и опера- ционной среды. Чтобы не придумывать недостижимые положения, нужно обеспечить взаимодействие разработчиков с маркетологами и аналитиками требований на весь период определения требований. Раз- работчики реально оценят, что можно выполнить технически, а что нет, или, что сделать можно, но при дополнительном финансировании. Ин-
бизнес-процессов
Компонент описания бизнес-
процесса
Элемент диаграммы деятельности (Activity
diagram)
Бизнес-процесс
(как набор взаимосвязанных видов дея- тельности, преобразующих вхо- ды в выходы)
Диаграмма деятельности, основными элемен- тами которой являются элементы Action (дей- ствие), Activity edge (связи между элементами
Action, изображающие либо передаваемые объекты, либо потоки управления), Partition
(отделения).
Модель бизнес-процесса (гра- фическое, табличное, текстовое, символьное описание бизнес- процесса либо их взаимосвязан-
Набор необходимых диаграмм деятельности, являющихся различными представлениями бизнес-процесса.
158 ная совокупность)
Владелец бизнес-процесса
(должностное лицо, которое управляет выполнением бизнес- процесса и несет ответствен- ность за его результаты и эф- фективность)
Может быть изображен при помощи элемента
Partition либо указан в виде текстового описа- ния.
Потребитель бизнес-процесса
(тот, кто использует или по- требляет результаты деятельно- сти)
Может быть изображен при помощи элемента
Partition.
Дополнительные атрибуты биз- нес-процесса (например, ис- пользуемые ресурсы, испол- няющие механизмы и т.д.)
Могут быть изображены при помощи элемен- тов Partition либо указаны при помощи элемен- та Note, прикрепляемого к необходимому эле- менту диаграммы деятельности.
Классификация действий, со- ставляющих бизнес процесс, в соответствии с заданными кри- териями
Может быть выполнена при помощи элементов
Partition.
Идентификация проблемных действий
Выделение соответствующих элементов Action цветом, классификация с использованием эле- ментов Partition.
Назначение исполнителей от- дельных действий в рамках биз- нес-процесса
Может быть выполнено при помощи элемен- тов Partition.
Возможность задать «каркас» выполнения процесса
Может быть выполнено при помощи элемен- тов Partition и StructuredActivity.
Деятельность по выявлению и анализу бизнес-процессов автомати- зируемой предметной области, безусловно, несколько выбивается из набора «обязательных для выполнения» процессов в ходе проекта по разработке программной системы. Более того, анализ существующих и проектирование на его основе новых бизнес-процессов может выпол- няться и не в рамках проекта по разработке программной системы, а, например, просто в рамках проекта по повышению эффективности дея- тельности организации и/или качества выпускаемой ею продукции и/или услуг. Для целей моделирования бизнес-процессов могут быть использованы различные специализированные нотации, такие как ARIS,
BPML, IDEF0 и др., и, соответственно, инструменты, их поддерживаю- щие, а также инструменты, поддерживающие унифицированный язык моделирования UML, предназначенный, прежде всего, для разработки программных систем.
IBM Rational Software Architect (RSA) является частью IBM Software
Development Platform – набора инструментов, поддерживающих жиз- ненный цикл разработки программных систем. RSA предназначен для построения моделей разрабатываемых программных систем с использо- ванием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Этот инструмент предоставляет возможность архитекторам и аналитикам создавать раз-
159 личные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработ- ку J2EE, XML, Web-сервисов и т.д. Кроме того, Rational Software
Architect поддерживает технологию разработки, управляемой моделями
(model-driven development, MDD), позволяющую моделировать про- граммное обеспечение на различных уровнях абстракции с возможно- стью трассируемости.
Хороший пример использования RSA для целей моделирования биз- неса приведен в [16]. Однако, если возможностей RSA, как правило, достаточно для построения моделей типа As-Is, то для построения мо- делей типа As-To-Be часто их недостаточно. Дело в том, что средства
RSA позволяют построить только статическую модель существующей на предприятии схемы бизнес-процессов и не позволяют промоделиро- вать производственный (или иной) процесс в динамике. Это не позволя- ет получить количественные характеристики (показатели) отдельных бизнес-процессов и всего производственного цикла, а также выявить узкие места как в организации отдельных бизнес-процессов, так и в це- лом во всем производственном цикле.
IBM предлагает другой инструмент – WebSphere® Business Modeler
(далее – Modeler), который считается лучшим в отрасли инструментом для моделирования и имитации бизнес-процессов [8]. С помощью
Modeler бизнес-аналитики и другие пользователи (даже далекие от про- грамммирования) могут создавать бизнес-модели для документирова- ния своих процессов, а затем осуществлять их имитационное моделиро- вание, чтобы понять поведение этих процессов «в динамике». Пользова- тели могут генерировать отчеты на основе модели процесса и по ре- зультатам имитационного моделирования.
Имитация позволит оценить эффективность бизнес-процессов, со- брать статистику выполнения процессов, выявить потенциальные об- ласти для их улучшения. Имитация бизнес-процессов – это, по сути, оценка эффективности реального бизнеса в виртуальной среде.
Имеется возможность экспортирования разработанных моделей в такие среды, как WebSphere Integration Developer (Integration Developer),
WebSphere Process Server (Process Server) и IBM FileNet P8 и хранения их в таких системах как Rational® ClearCase и Rational Asset Repository.
Модели могут быть опубликованы с помощью компонента WebSphere
Business Modeler Publishing Server (Publishing Server), что позволяет ав- торизованным пользователям просматривать эти модели с помощью
Web-браузера. Эти модели могут также быть связаны с требованиями в продукте Rational RequisitePro и повторно использованы в продукте
Rational Software Architect. В версии Modeler 6.2, в дополнение к пере- численным возможностям, реализован ряд важных усовершенствований
[21].
В частности реализована новая возможность, позволяющая бизнес- пользователям развертывать свои проекты для моделирования и мони- торинга бизнес-процессов непосредственно на продуктах Process Server и WebSphere Business Monitor (Monitor). После того как проекты раз-
160 вернуты, автоматически создается новое бизнес-пространство под на- званием Test Space (пространство тестирования), в состав которого вхо- дят элементы («виджеты») для исполнения, управления и мониторинга процессов. Помимо прочего, эта новая функциональность под названи- ем design to deploy (от проектирования до развертывания) поддерживает некоторые сценарии для рабочих процессов персонала.
Пользователи продукта Integration Developer могут вносить свой вклад в отладку проектов design to deploy. Этот сценарий под названием time to value сокращает число итераций между бизнесом и ИТ, благода- ря чему ускоряется проведение процесса. ИТ-специалисты по-прежнему должны участвовать в процессе, однако объем возлагаемой на них обя- зательной работы может быть уменьшен, в результате чего увеличива- ются возможности бизнес-пользователей и сокращается время до полу- чения экономического эффекта.
После того как модель будет полностью протестирована, можно ис- пользовать функциональность design to deploy для проверки возможно- стей мониторинга модели с использованием одного из готовых шабло- нов мониторинга.
4.4.3.
Определение функциональных требований
Функциональные требования описывают сервисы, представляемые программной системой, ее поведение в определенных ситуациях, реак- цию на те или иные входные данные и действия, которые система по- зволит выполнить пользователям. Иногда сюда добавляются сведения о том, что система не должна делать.
При написании функциональных требований необходимо учитывать, что чем они будут подробнее, тем более точная оценка работ по стоимо- сти и срокам будет дана в техническом задании (ТЗ). Если на дальней- ших этапах разработки ПС не возникнет дополнений к изначально сформулированным функциональным требованиям, то эта оценка будет достаточно точной.
Функциональные требования удобно представлять в виде диаграмм вариантов использования. Вариант использования представляет собой последовательность действий, выполняемых системой, в ответ на собы- тия, инициируемые внешним объектом (действующим лицом – актором по терминологии, принятой в ряде публикаций [10]). Такие диаграммы используются в RUP-технологии разработки программных проектов
[17].
Вариант использования описывает типичное взаимодействие между пользователем и системой и отражает представление о поведении сис- темы с точки зрения пользователя. В простейшем случае вариант ис- пользования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать, или целей, которые он пре- следует по отношению к разрабатываемой системе.
161
Модель варианта использования дает подробную информацию о поведении системы или приложения. Она определяет требования сис- темы в терминах требующейся функциональности (варианты использо- вания) для достижения целей или для решения проблемы, определенной пользователем, и она же описывает окружение (агенты) и отношения между вариантами использования и агентами (диаграммы вариантов использования). Модель варианта использования также включает диа- граммы вариантов и диаграммы действий, которые описывают то, как пользователи общаются с системой.
Модель вариантов использования имеет следующие достоинства: определят пользователей и границы системы; определяет системный интерфейс; удобна для общения пользователей с разработчиком; используется для написания тестов; является основой для написания пользовательской документации; хорошо вписывается в любые методы проектирования (как объект- но-ориентированные, так и структурные).
В дополнение к вариантам использования необходимо определить, как должен выглядеть пользовательский интерфейс для реализации ка- ждого варианта использования. подготовить эскизы, обсудить их с пользователями, возможно, создать прототипы и отдать их на тестиро- вание пользователям. Следует также иметь в виду, что каждый конкрет- ный пользователь работает с системой по-своему, поэтому для опреде- ления действительных вариантов использования системы необходимо досконально знать потребности всех заинтересованных пользователей, провести анализ полученной информации и систематизировать ее в дей- ствительные варианты использования системы, т.е. абстрагироваться от конкретных пользователей и исходить из бизнес-задач организации- заказчика.
Требования могут быть представлены в различных формах – от не- структурированного текста до выражений формального языка. Боль- шинство функциональных требований к системе, могут быть выражены в виде вариантов использования.
Диаграммы вариантов использования – один из видов диаграмм
UML, предназначенных для моделирования динамических аспектов систем. Это основной вид диаграмм при моделировании поведения сис- темы и требований, предъявляемых к системе. Формулирование требо- ваний к системе, по сути представляет собой составление контракта между ней и теми сущностями, которые находятся вне ее. Этот контракт декларирует, что система должна делать. Хорошая система выполняет требования точно, предсказуемо и надежно. Удобным инструментом построения диаграмм использования является IBM Rational Software
Architect (RSA) – часть IBM Software Development Platform – набора инструментов, поддерживающих жизненный цикл разработки про- граммных систем.
162
Продукт IBM Rational Software Architect предназначен для построе- ния моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моде- лей архитектуры разрабатываемого приложения. RSA объединяет в себе функции таких программных продуктов, как Rational Application
Developer, Rational Web Developer и Rational Software Modeler, тем са- мым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработ- ку J2EE, XML, Web-сервисов и т.д. Следуя принципам RUP, Rational
Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как:
Бизнес анализ и моделирование (Business modeling).
Управление требованиями (Requirements).
Анализ и проектирование (Analysis and Design).
Реализация (Implementation).
Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемости.
Правильно сформулированные функциональные требования должны обладать следующими характеристиками.
1. Полнота. Каждое требование должно полно описывать функцио- нальность, которую следует реализовать в продукте. Оно должно со- держать всю информацию, необходимую для разработчиков, чтобы им удалось создать этот фрагмент функциональности. Если данных опре- деленного рода не хватает, следует помечать такие требования (необхо- димо определить) на полях, как стандартный флаг для выделения такого места. Все пробелы в каждом фрагменте требований следует воспол- нить, прежде чем приступать к конструированию этой функции.
2. Корректность. Каждое требование должно точно описывать же- лаемую функциональность. Для соблюдения корректности необходима связь с источниками требований, например, с пожеланиями пользовате- лей или высокоуровневыми системными. Требования к ПО, которые конфликтуют с родительскими требованиями, нельзя считать коррект- ными. Однако основная оценка здесь – за представителями пользовате- лей, вот почему им или их непосредственным заместителям необходимо предоставлять требования для просмотра.
3. Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и опера- ционной среды. Чтобы не придумывать недостижимые положения, нужно обеспечить взаимодействие разработчиков с маркетологами и аналитиками требований на весь период определения требований. Раз- работчики реально оценят, что можно выполнить технически, а что нет, или, что сделать можно, но при дополнительном финансировании. Ин-