Концепция новой ИС

Standard glossary of Software Engineering Terminology (1990) определяет требования как:
условия

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

и процесс обработки информации.
Нефункциональные требования определяют атрибуты системы или

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

следующую модель требований, разбивая функциональные требования по трем уровням: бизнес-требования,

требования пользователей и функциональные требования

Бизнес-требования

Системные требования

Требования пользователей

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

Атрибуты качества

Бизнес-правила

Внешний интерфейс

Ограничения

Документ об образе и границах

Документ о вариантах использования

Спецификация требований к ПО

Функциональные

Нефункциональные

кто финансирует проект или покупает систему или менеджер реальных пользователей.

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

- цели и критерии успеха
Потребности клиента или рынка
Бизнес - риски
Образ

решения
Положение об образе проекта
Основные функции
Предположения и зависимости
Масштабы и ограничения проекта
Объем первоначально запланированной версии
Объем последующих версий
Ограничения и исключения
Бизнес-контекст
Профили заинтересованных лиц
Приоритеты проекта
Операционная среда

Они могут быть описаны с помощью:
вариантов использования (методология RUP),
сценариев

(методология SADT);
таблиц «событие – отклик».

могли выполнить свои задачи в рамках бизнес-требований.
Они могут быть

описаны как требования поведения, например: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

обеспечение,
подсистемы ПО,
оборудование
людей.

Они не являются требованиями к ПО, поскольку находятся вне системы,

но они накладывают ограничения.

продукта, выраженное через описание его характеристик, важных для пользователей или

разработчиков.
К таким характеристикам относятся:
легкость и простота использования,
легкость перемещения,
целостность,
эффективность,
устойчивость к сбоям.
Ограничения касаются выбора возможности разработки внешнего вида и структуры продукта.

где описывается поведение системы.
Этот документ может быть представлен в

любом виде, в том числе и в виде базы данных, электронной таблицы, набора карточек (для небольшой системы).

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

Requirements Specifications» (IEEE, 1998b))
1.Введение
1.1. Назначение
1.2. Соглашения, принятые в документах
1.3. Предполагаемая

аудитория и рекомендации по чтению
1.4. Границы проекта
1.5. Ссылки
2. Общее описание
2.1. Общий взгляд на продукт
2.2. Особенности продукта
2.3. Классы и характеристики пользователей
2.4. Операционная среда
2.5. Ограничения дизайна и реализации
2.6. Документация для пользователей
2.7. Предположения и зависимости

3. Функции системы
3.х Функция системы x
3.х.1. Описание и приоритеты
3.х.2. Последовательности «воздействие – реакция»
3.х.3. Функциональные требования
4. Требования к внешнему интерфейсу
4.1. Интерфейсы пользователя
4.2. Интерфейсы оборудования
4.3. Интерфейсы ПО
4.4. Интерфейсы передачи информации
5.Другие нефункциональные требования
5.1. Требования к производительности
5.2. Требования к охране труда
5.3. Требования к безопасности
5.4. Атрибуты качества
6. Остальные требования
7. Приложения

документирование и утверждение. В эти этапы входят следующие действия:

с заказчиками по поводу требований к разрабатываемому ПО». Это соглашение

воплощается в спецификации (в письменной форме) и моделях. Более того, разработчики также должны принять задокументированные требования и высказаться за создание этого продукта. К действиям по управлению требованиями относятся:
определение основной версии требований (моментальный срез требований для конкретной версии продукта);
просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
включение одобренных изменений требований в проект установленным способом;
согласование плана проекта с требованиями;
обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
отслеживание отдельных требований до их дизайна, исходного кода и вариантов тестирования;
отслеживание статуса требований и действий по изменению на протяжении всего проекта.

текущая версия отредактированная версия


изменение изменение
требований проекта

Анализ, документирование, просмотр, обсуждение

Основная версия

Процесс изменения требований

Сотрудники отдела маркетинга, заказчики, менеджеры

Разработка требований

Управление требованиями

Сотрудники отдела маркетинга, заказчики, менеджеры

Окружающая среда проекта

должен отвечать следующим характеристикам:

человек или организация, получающая от продукта прямую или косвенную выгоду. Каждому

клиенту соответствует свой уровень требований

Заказчик системы, менеджер, отдел маркетинга

Конечные пользователи

обязан
1. Иметь дело с аналитиком, который разговаривает на вашем языке
2.

Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается
система
3. Потребовать, чтобы аналитик преобразовал требования, предоставленные вами устно,
в письменную спецификацию требований к программному продукту
4. Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных
в процессе формулирования требований
5. На уважительное и профессиональное отношение к вам со стороны аналитиков
и разработчиков
6. Знать о вариантах и альтернативах требований и их реализации
7. Описать характеристики, упрощающие работу с продуктом
8. Изменить требования или разрешить использование имеющихся программных компонентов
Э. Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых
компромиссах, которые возникают в связи с изменениями в ПО
10. Потребовать, чтобы система функциональностью и качеством удовлетворяла требования
заказчика

1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса
2. Потратить столько времени, сколько необходимо, на объяснение требований
3. Точно и конкретно описать требования к системе
4. Принимать своевременные решения
5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших
требований
6. Определять приоритеты требований
7. Просматривать документы с требованиями и оценивать прототипы
8. Своевременно сообщать об изменениях требований
9. Поддерживать принятый в организации-разработчике порядок контроля изменений
10. Уважительно относиться к методам, с помощью которых аналитики создают требования

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

На практике эти действия выполняются попеременно, поэтапно и повторяются. Работая с клиентами в качестве аналитика, вы будете задавать вопросы, выслушивать ответы и наблюдать за действиями клиентов (выявление требований).

Далее вы обработаете полученную информацию, классифицируете по различным категориям и соотнесете потребности клиентов с возможными требованиями к ПО (анализ).

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

Этот итерационный процесс и есть процедура создания требований.

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

На следующем слайде показана схема создания требований, которая с разумными исправлениями подойдет для большинства проектов.
Как правило, действия выполняются в основном по порядку, однако сам процесс не является строго последовательным.
Первые семь действий обычно однократно выполняются на ранних стадиях работы нал проектом (тем не менее команде разработчиков придется периодически изменять приоритеты). Остальные необходимы для каждого очередного выпуска или этапа работы над проектом.
Оценив доступные вам способы общения с представителями пользователей, выберите подходящие приемы выявления требований (круглые столы, исследования, опросы и т.д.) и спланируйте время и ресурсы, необходимые для сбора информации (этап 5 на слайде).
Многие системы создаются поэтапно, и поэтому любой команде, работающей над проектом, необходимо определить приоритеты вариантов использования и других пользовательских требований (этап 7). Расставив приоритеты, вы решите, на каком этапе следует реализовать те или иные варианты использования. В случае новых систем или значительных усовершенствований можно на этапе 14 определить или уточнить архитектуру, а на этапе 15 распределить функциональные требования по конкретным подсистемам. Этапы 12 и 17 — это операции по контролю качества, в результате которых вам, возможно, придется вернуться, чтобы исправить ошибки, улучшить модели анализа или выявить упущенные ранее требования. Прототипы, создаваемые на этапе 13, зачастую выявляют необходимость усовершенствовать и модифицировать определенные ранее требования. Завершив для какой-либо части требований этап 17, можно приступать к реализации соответствующей части системы.
Повторите этапы 8—17 для следующих наборов вариантов использования, которые могут войти в более позднюю версию продукта.

- цели и критерии успеха
Потребности клиента или рынка
Бизнес - риски
Образ

решения
Положение об образе проекта
Основные функции
Предположения и зависимости
Масштабы и ограничения проекта
Объем первоначально запланированной версии
Объем последующих версий
Ограничения и исключения
Бизнес-контекст
Профили заинтересованных лиц
Приоритеты проекта
Операционная среда

document) собирает бизнес-требования в единый документ, который подготавливает основу для

последующей разработки продукта.
В некоторых организациях с этой же целью создают устав проекта или положение о бизнес-задачах. Очень полезен и документ основных рыночных требований {market requirements document, MRD). В нем более детально, чем в документе об образе и границах, рассматриваются целевые сегменты рынка и проблемы, касающиеся коммерческого успеха продукта.
Владельцем документа об образе и границах считается тот, кто финансирует проект или несет аналогичную ответственность. Аналитик требований может вместе с этим человеком разрабатывать документ об образе и границах проекта. Информация, касающаяся бизнес-требований, должны поступать от лиц, четко понимающих, почему они взялись за проект. Это может быть клиент или топ-менеджер организации, разрабатывающей продукт, тот, кого привлекают технические новинки, менеджер по продукту, эксперт в данной предметной области или специалисты отдела маркетинга.

кого-то сделает мир лучше.
Бизнес-требования описывают основные преимущества, которые новая

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

модели бизнес-процесса мы ставили цель: увеличение потока продаж, поскольку это

позволит увеличить прибыль предприятия.
На этом этапе формирования требований должна быть уточнена бизнес-цель подразделения и выбрана модель управления.
Эта процедура может быть выполнена только топ - менеджментом предприятия с учетом бизнес - цели предприятия.
Бизнес-требование в дальнейшем окажет влияние на выбор модели новой ИС. Бизнес-требование и будущая модель системы управления предприятием и, как следствие, новая ИС связаны между собой.
На различных уровнях управления предприятием выбираются различные модели управления.
Эти модели должны быть гармонизированы.

следующие модели управления: ERP, MRP; CRM и другие.
Наша предметная область

связана с заказчиками и другими подразделениями предприятия (производственный отдел, склад, касса, отдел договоров).
Эффективность всего предприятия будет зависеть от прибыли, которая, в свою очередь, зависит от успешных продаж крепежных изделий заказчику, отгрузки крепежных изделий по договорам точно в срок, уменьшения срока хранения готовых изделий на складе.
Поэтому из всех моделей управления на этом уровне управления логичнее всего предложить заказчику
модель CRM - модель управления отношений с заказчиками.

при продажах;
выявление новых источников прибыли;
интеграция в общую среду информационной системы

предприятия, в том числе финансовую и производственную;
организация приема и обработки данных, поступающих по различным каналам связи, включая Web, телефонные каналы, электронную почту и т.д.

помещают общее описание предыстории или ситуации, в результате которых было

принято решение о создании продукта.
Пример:
Исходные данные, возможности бизнеса и нужды клиента:
Заказчик «Метиз-М» тратит в среднем 1 - 2 часа на обслуживание в отделе продаж (проверка готовности заказа на складе, ожидание подготовки сопроводительных документов). Сотрудник отдела продаж тратит на обслуживание одного заказчика не менее 40 минут. Он обслуживает за день 8 – 10 клиентов. Времени на подготовку аналитических документов для руководителя отдела продаж не достаточно.
Клиенты хотели бы получать информацию о продукции «Метиз-М» по сети и по сети посылать заявку на приобретение продукции. Получать счета по электронной почте. Оплачивать продукцию не только в кассе, но и с помощью безналичных расчетов. Осуществлять непосредственные контакты с сотрудником отдела продаж только при получении сопроводительных документов на готовую продукцию. Это позволит не только уменьшить время на обслуживание клиента, улучшить качество обслуживания, но и получать дополнительную информацию о заказчиках продукции «Метиз-М», и усовершенствовать каналы продаж.

и рынок, на котором продукту придется конкурировать с другими продуктами.

Для корпоративной информационной системы описывают бизнес-проблему, которая разрешается посредством этого продукта, или бизнес-процессы, для улучшения которых требуется продукт, а также среду, в которой система будет использоваться.
Кроме того, приводится сравнительная оценка существующих продуктов и возможных решений, указав, в чем заключается привлекательность продукта и его преимущества. Описываются проблемы, которые не удается разрешить без продукта. Показывается, насколько он соответствует тенденциям рынка, развитию технологий или корпоративной стратегии. Кратко описываются другие технологии, процессы или ресурсы, необходимые для удовлетворения клиента.
Разобрать пример.

продуктом, в количественном и измеряемом виде.
В таблице приведены примеры

и финансовых и нефинансовых целей (Wiegers, 2002с). Если подобная информация приведена где-то еще, например в документе о бизнес-задачах, сошлитесь на этот документ, а не копируйте информацию.
Определите, как заинтересованные лица будут определять и измерять успех проекта (Wiegers, 2002с).
Установите факторы, которые максимально влияют на успех проекта — и те, которые организация может контролировать, и те, которые находятся вне сферы ее влияния.
Определите меру для оценки того, были ли достигнуты бизнес-цели.

X на Y% за Z месяцев
Достигнуть объема продаж X единиц

или дохода, равного $Y, за Z месяцев
Получить Х% прибыли или дохода по инвестициям в течение Y месяцев
Достигнуть положительного баланса по этому продукту в течение Y месяцев
Сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы
Уменьшить затраты на поддержку на Х% за Z месяцев
Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара
Увеличить валовую прибыль для существующего бизнеса с Х до Y%

Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска товара
Увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%
Достигнуть определенного времени для достижения доминирующего положения на рынке
Разработать надежную платформу для семьи связанных продуктов
Разработать специальную базовую технологическую основу для организации
Получить X положительных отзывов в отраслевых журналов к определенной дате
Добиться признания продукта лучшим по надежности в опубликованных обзорах продуктов к определенной дате
Соответствовать определенным федеральным и государственным постановлениям
Уменьшить время оборота до X часов на Y% звонков покупателей в службу поддержки

рабочее время каждого сотрудника на обслуживание заказчика до 20 минут

в течение 3 месяцев после первого выпуска информационной системы.
Бизнес - цель 2. Уменьшение времени заказчика для оформления заказа не более 1 часа с учетом двух возможностей: сетевого обслуживания и непосредственного контакта с клиентом в течение 3 месяцев после выпуска системы.
Бизнес – цель 3. Увеличить число продаж на 50% в течение 3 месяцев после первого выпуска информационной системы.
Критерий успеха 1. Все сотрудники отдела продаж, работающие с заказчиками, должны в течение 2 месяцев после первого выпуска системы перейти на работу с ИС.
Критерий успеха 2. Выявление новых источников (увеличение на 50%) прибыли за счет поиска новых каналов продаж в течение 12 месяцев после запуска ИС (экспертная оценка).

целевых сегментов рынка, включая потребности, которые не удовлетворяют настоящие продукты

или информационные системы. Представьте проблемы, с которыми в настоящее время сталкиваются клиенты и которые решит новая система, и предоставьте примеры того, как покупатели будут использовать этот продукт. Определите на высоком уровне все известные важные требования к интерфейсу или производительности, но не касайтесь деталей дизайна или реализации.
1.5 Бизнес-риски
Обобщает важнейшие бизнес-риски, связанные с разработкой — или не с разработкой — этого продукта. В категории рисков входят рыночная конкуренция, временные факторы, приемлемость для пользователей, проблемы, связанные с реализацией, и возможные негативные факторы, влияющие на бизнес. Оцените возможные потери от каждого фактора риска, вероятность его возникновения и вашу способность контролировать его. Определите все возможные действия по смягчению ситуации. Если вы уже подготовили эту информацию для анализа бизнес-задач или похожего документа, ссылайтесь на этот источник, а не копируйте эту информацию здесь.

1. Введение новых форм обслуживания заказчиков зависит от уровня информатизации

организации-заказчика. Не все заказчики готовы к новой форме обслуживания. Вероятность = 0,5.
Фактор бизнес – риска 2. Не все сотрудники отдела продаж готовы к работе с новой ИС. Потребуются финансовые и временные ресурсы на обучение персонала. Вероятность = 0,6.
Фактор риска 3. Возможна реструктуризация отдела продаж и изменение функций сотрудников отдела продаж. Вероятность = 0,8.

позволяющей выполнять бизнес-задачи.
Этот образ обеспечивает основу для принятия решений

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

образе проекта, обобщающее долгосрочные цели и назначение нового продукта. В

этом документе следует отразить сбалансированный образ, удовлетворяющий различные заинтересованные лица. Он может быть несколько идеалистичным, но должен быть основан на существующих или предполагаемых рыночных факторах, архитектуре предприятия, стратегическом направлении развития корпорации или ограничениях ресурсов.
Далее показан шаблон, состоящий из ключевых слов, который прекрасно подходят для документа об образе продукта (Moore, 1991);
- для [целевая аудитория покупателей];
- который [положение о потребностях или возможностях];
- эта (этот) [имя продукта]
- является [категория продукта];
- который(ая) [ключевое преимущество, основная причина для покупки или использования];
- в отличие от [основной конкурирующий продукт, текущая система или текущий бизнес-процесс];
- наш продукт [положение об основном отличии и преимуществе нового продукта].

представлять собой Интернет-приложение, позволяющее ознакомиться с номенклатурой производимых крепежных изделий,

оформить заявку на покупку готовых изделий.
Кроме того, эта система позволит произвести оплату покупаемой продукции (электронные платежи).
Для сотрудников отдела продаж информационная система представляет собой приложение, представляющее информацию о готовой продукции на складе, готовить сопроводительные документы, отправлять информацию в отдел договоров о закрытии договора.
Для топ-менеджеров предприятия информационная система представляет собой приложение, которое готовит аналитические отчеты о продажах, выдает целостное представление о потребителе крепежных изделий.

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

те из них, которые отличают его от предыдущих или конкурирующих продуктов. Дав каждой функции уникальное имя (в отличие от маркера абзаца), вы сможете отеследить каждую функцию до отдельных требований пользователей, функциональных требований и других элементов систем.
2.3 Предположения и зависимости
Задокументируйте все предположения, сделанные заинтересованными лицами, когда они обдумывали проект и создавали данный документ об образе и границах. Часто предположения одних лиц не разделяют другие стороны. Если вы запишите их и просмотрите позже, то получите возможность обговорить основные положения проекта. Так вы избежите путаницы и ухудшения ситуации в будущем. Также задокументируйте: важнейшие зависимости проекта от внешних факторов — изменения индустриальных стандартов или правительственных положений, других проектов, поставщиков со стороны или партнеров по разработке.

текущей номенклатуры готовой продукции (прайс-лист «Метиз-М»).
Основные функции 2. Предоставление бланка-заказа

готовой продукции клиенту, прием бланка-заказа от клиента.
Основные функции 3. Запрос на склад о требуемой продукции.
Основные функции 4. Создание счета на оплату, предоставление счета клиенту.
Основные функции 5. Создание сопроводительных жокументов на оплаченную продукцию.
Основные функции 6. Изменение состояния склада после продажи продукции.
Основные функции 7. Запрос на отгрузку оплаченной продукции.
Основные функции 8. Создание сообщения в отдел договоров о закрытии договора.
Основные функции 9. Создание и выдача текущих и аналитических отчетов.
Основные функции 10. Обеспечение доступа к системе через корпоративную сеть интранет или через Интернет для авторизованных пользователей.

определить его рамки и ограничения. Вам необходимо указать, что может

делать система, а что не может.
Границы проекта определяют концепцию и круг действия предложенного решения.
В ограничениях указываются определенные возможности, которые не будут включены в продукт.
Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц. Иногда клиенты запрашивают функции, слишком дорогостоящие или выходящие за предполагаемые границы продукта. Требования, выходящие за границы продукта, следует отклонять, если только они не настолько ценны, чтобы специально под них расширить проект, естественно, соответствующим образом изменив в бюджет, график и кадровый состав.
Документируйте отклоненные требования и причины отказа от них, поскольку они имеют свойство появляться снова.

функции, включенные в первоначальную версию продукта.
Опишите характеристики качества, которые

позволят продукту предоставлять предполагаемые выгоды различным классам пользователей. Если ваша задача — сосредоточиться на разработке и уложиться в график, вам следует избегать искушения включить в версию 1.0 каждую функцию, которая когда-нибудь в будущем может понадобиться какому-то потенциальному покупателю.
Увеличение сроков и сдвиг графика— типичный исход такого коварного расползания объема.
Сосредоточьтесь на наиболее ценных функциях, имеющих максимально приемлемую стоимость, годных для самой широкой целевой аудитории, которые удастся создать как можно раньше,
Версия 1 не обязательно должна быть быстрой, красиво оформленной или легкой в использовании, но она должна быть надежной; это основа работы команды.
Первая версия системы выполняет лишь базовые задачи.
В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие легкость и простоту использования.

поэтапную эволюцию продукта, укажите, какие из функции будут отложены и

желательные сроки последующих выпусков. В последующих версиях вы сможете реализовать дополнительные варианты использования и функции и расширить возможности первоначальных вариантов использования и функций (Nejmeh и Thomas, 2002). Вы также сможете повысить производительность, надежность и другие характеристики качества по мере совершенствования продукта. Чем дальше вы заглядываете, тем более расплывчатыми будут границы проекта. Вам наверняка придется передвинуть функциональность с одного запланированного выпуска до другого и, возможно, добавлять незапланированные функции. Короткие циклы выпуска часто удобны для сбора отзывов клиентов.
3.3 Ограничения и исключения
Определение границы между тем, что входит и выходит за границы проекта, — отличный способ управления расползанием объема и ожиданиями клиентов. Перечислите все возможности или характеристика которых могут ожидать заинтересованные в проекте лица, но включение которых в продукт или в определенную версию не запланировано.

основных категорий заинтересованных лиц и приоритеты управления.
4.1 Профили заинтересованных лиц
Заинтересованными

в проекте лицами (stakeholders) называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могу" влиять на этот результат (Project Management Institute, 2000; Smitr, 2000). Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте. Вам не нужно описывать каждую группу заинтересованных лиц, например юристов, которые проверяют соответствие надлежащим законам. Сферой вашего интереса должны стать различные группы клиентов, целевые рыночные сегменты и различные классы пользователей, входящих в эти сегменты. В профиль каждого заинтересованного в проекте лица включается следующая информация:
-основная ценность или преимущество, которое продукт принесет заинтересованным лицам и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц представляют:
1. улучшенная производительность;
2. меньшее количество переделок;
3. снижение себестоимости;
4. ускорение бизнес-процессов;
5. автоматизация задач, ранее выполнявшихся вручную;
6. возможность выполнять совершенно новые задачи;
7. соответствие соответствующим стандартам и правилам;
8. лучшая, по сравнению с текущими продуктами, легкость и простота использования;
- их вероятное отношение к продукту;
- наиболее интересные функции и характеристики;
- все известные ограничения, которые должны быть соблюдены.

договориться о приоритетах проекта. Один из подходов к этому заключается

в рассмотрении пяти измеряемых параметров проекта: функции (или объем), качество, график, затраты и кадры (Wiegers. 1996а). В любом проекте каждый из этих параметров относится к одной из трех категорий:
ограничение — лимитирующий фактор, в рамках которого должен оперировать менеджер проекта;
ключевой фактор — важный фактор успеха, ограниченно гибкий при изменениях;
степень свободы — фактор, который менеджер проекта может до определенной степени изменять и балансировать относительно других параметров.
Задача менеджера проекта — настроить те факторы, которые представляют собой степени свободы для достижения ключевых факторов успеха проекта е рамках, налагаемых ограничениями. Не все факторы могут быть ключевыми, как и не все — ограничениями. Менеджеру проекта необходима определенная степень свободы для того, чтобы он мог реагировать должным образом на изменение требований к проекту или внешних обстоятельств.
Представьте себе, что отдел маркетинга неожиданно требует создать продукт на месяц раньше сроке. Какова будет ваша реакция?
Вы отложите реализацию определенных требований до более поздней версии?
Сократите запланированный цикл тестирования системы?
Оплатите сверхурочную работу вашим специалистам или пригласите специалистов по контракту для ускорения разработки?
Привлечете ресурсы других проектов для разрешения ситуации?
Именно от приоритетов проекта зависят ваши действия в подобных ситуациях.

и определите важнейшие требования к доступности, надежности, производительности и целостности.

Эта информация существенно влияет на определение архитектуры системы, что является первым — и часто самым важным— этапом дизайна. Архитектура системы, предназначенной для поддержки пользователей, которые находятся далеко друг от друга и которым необходим круглосуточный доступ, сильно отличается от той, что предназначена для доступа пользователей, находящихся рядом, только в рабочие часы. На нефункциональные требования, такие. как отказоустойчивость и способность обслуживать систему во время ее работы, требуется значительное количество средств, отпущенных на дизайн и реализацию. Чтоб прояснить ситуацию, задайте заинтересованным лицам уточняющие вопросы.
Пользователи расположены далеко (географически) или близко друг от друга? В скольких часовых поясах работают ваши пользователи?
Когда пользователям, находящимся в различных географических местоположениях, требуется доступ к системе?
Где данные генерируются и используются? Насколько далеко друг от друга расположены эти местоположения? Нужно ли объединять данные из разных местоположений?
Известно ли максимальное время отклика для получения доступа к данным, которые могут храниться удаленно?
Готовы ли пользователи смириться с прерыванием работы службы или непрерывный доступ к системе крайне важен для работы их компании?
Какие элементы управления безопасностью и требования к защите данных необходимы?

информации от клиентов зависят от специфики продукта и среды разработки.

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

продукта;
по опыту в предметной области и опыту работы с компьютерными

системами;
по требуемой им функциональности;
по задачам, которые им приходится выполнять;
по правам доступа к системе (например, обычный пользователь, гость или администратор).
На их основе формируются классы пользователей.
Некоторых сотрудников можно отнести к нескольким классам.
Так, администратор иногда работает с системой, как рядовой пользователь.

определяет, способствует ли он достижению заявленных бизнес-целей или нет. Это

не означает, что заинтересованных лиц, оплачивающих разработку системы (они, вполне вероятно, вообще не являются ее пользователями), или тех, кто имеет большое политическое влияние, следует обязательно включать в привилегированные классы.
Непривилегированные классы составляют те пользователи, которые по причинам безопасности, конфиденциальности или правовым причинам не работают с продуктом (Cause и Lawrence, 1999).
Остальные классы пользователей можно проигнорировать.

продукта

описывает последовательность взаимодействия системы и внешнего действующего лица.
Действующим лицом (actor)

может быть человек, другая система ПО или аппаратное устройство, взаимодействующее с системой для доcтижения некой цели (Cockburn, 2001). Еще одно название действующего лица — роль пользователя, поскольку это роль, которую члены одного или нескольких классов пользователей могут выполнять по отношению к системе (Constantine и Lockwood, 1999).
Варианты использования меняют традиционный подход к сбору информации; пользователей не спрашивают, как прежде, что, с их точки зрения, должна делать система, а выясняют, какие задачи собирается с ее помощью решать пользователь.
Цель такого подхода — описать все подобные задачи.

к сбору информации; пользователей не спрашивают, как прежде, что, с

их точки зрения, должна делать система, а выясняют, какие задачи собирается с ее помощью решать пользователь.
Цель такого подхода — описать все подобные задачи. До включения каждого варианта использования в утвержденную версию требований, заинтересованные в проекте лица проверяют, не выходит ли он за границы проекта.
Теоретически в конечный набор вариантов использования должна входить вся желаемая функциональность системы.
На практике же вам вряд ли удастся добиться стопроцентного результата, однако варианты использования помогут вам выполнить эту задачу полнее, чем какой-либо другой прием сбора информации, которым я когда-либо пользовался

лицо может выполнить для получения определенного значимого результата.
Один вариант

использования может охватывать несколько схожих задач с одинаковыми целями. Следовательно, он представляет собой набор связанных между собой сценариев использования, где сценарий — это отдельный пример варианта использования.
Вы можете начать разработку требований с абстрактных вариантов использования, а затем на их основе создать конкретные сценарии использования или, наоборот, перейти от некоего сценария к более широкому варианту использования. К важным элементам описания варианта использования относятся:
уникальный идентификатор;
имя, кратко описывающее задачи пользователи в формате ≪глагол + объект≫, например ≪разместить заказ≫;
краткое текстовое описание на естественном языке;
список предварительных условий, которые должны быть удовлетворены до начала разработки варианта использования;
выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования;
пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных условий.

его также называют основным направлением, базовым направлением, нормальным потоком, основным

сценарием, главным успешным сценарием и благоприятным путем.
Другие допустимые сценарии из варианта использования, называются альтернативными направлениями (alternative courses) или вторичными сценариями (secondary scenarios) (Schneider и Winters, 1998).
Они также могут привести к успешному выполнению задания и удовлетворяют выходным условиям варианта использования. Однако они представляют вариации решения задачи или диалоговой последовательности, необходимой для выполнения задачи.

требования
Предположения
Замечания и вопросы

ним относятся:
заказчик,
сотрудник отдела продаж, обслуживающий заказчиков,
руководитель отдела

продаж,
кассир,
кладовщик,
менеджер отдела договоров,
сотрудник производственного отдела,
сотрудник отдела цен.

Requirements Specifications» (IEEE, 1998b))
1.Введение
1.1. Назначение
1.2. Соглашения, принятые в документах
1.3. Предполагаемая

аудитория и рекомендации по чтению
1.4. Границы проекта
1.5. Ссылки
2. Общее описание
2.1. Общий взгляд на продукт
2.2. Особенности продукта
2.3. Классы и характеристики пользователей
2.4. Операционная среда
2.5. Ограничения дизайна и реализации
2.6. Документация для пользователей
2.7. Предположения и зависимости

3. Функции системы
3.х Функция системы x
3.х.1. Описание и приоритеты
3.х.2. Последовательности «воздействие – реакция»
3.х.3. Функциональные требования
4. Требования к внешнему интерфейсу
4.1. Интерфейсы пользователя
4.2. Интерфейсы оборудования
4.3. Интерфейсы ПО
4.4. Интерфейсы передачи информации
5.Другие нефункциональные требования
5.1. Требования к производительности
5.2. Требования к охране труда
5.3. Требования к безопасности
5.4. Атрибуты качества
6. Остальные требования
7. Приложения

принципе использования спецификации требований к ПО.
1.1 Назначение
Определите продукт или приложение,

требования для которого указаны в этом документе, в том числе редакцию или номер выпуска. Если эта спецификация требований к ПО относится только к части системы, идентифицируйте эту часть или подсистему.
1.2 Соглашения, принятые в документах
Опишите все стандарты или типографические стандарты, включая стили текста, особенности выделения или замечания. Например, укажите, унаследован ли приоритет, указанный для требований высшего уровня, всеми их детализированными требованиями, или каждое положение о функциональных требованиях должно обладать собственным приоритетом.
1.3 Предполагаемая аудитория и рекомендации по чтению
Перечислите пользователей, для которых предназначена эта спецификация требований к ПО. Опишите содержание документа и его структуру. Порекомендуйте наиболее подходящую для каждого класса читателей последовательность чтения документа.

связан продукт с пользователями или корпоративными целями, а также с

бизнес-целями и стратегиями. Если имеется отдельный документ об образе и границах проекта, не повторяйте его содержимое, а просто сошлитесь на него. Если спецификацию требований к ПО предполагается разрабатывать постепенно, она должна содержать собственное положение об образе и границах продукта в качестве подраздела долгосрочного стратегического образа.
1.5 Ссылки
Перечислите все документы или другие ресурсы, на которые вы ссылаетесь в этой спецификации, в том числе гиперссылки на них. Это могут быть руководства по стилям пользовательского интерфейса, контракты, стандарты, спецификации к системным требованиям, документы о вариантах использования, спецификации интерфейса, концептуальные документы и спецификация требований к ПО для продуктов, на которые вы ссылаетесь. Объем информации должен быть достаточным для того, чтобы пользователь сумел при необходимости получить доступ к каждому указанному материалу, а именно: название, имя автора, номер версии, дата и источник или расположение (например, сетевая папка или URL)

и среды, в которой он будет применяться, предполагаемая пользовательская аудитория

а также известные ограничения, предположения и зависимости.

2.1 Общий взгляд на продукт
Опишите содержание и происхождение продукта. Поясните, является он новым членом растущего семейства продуктов, новой версией существующей системы, заменой существующего приложения или совершенно новым продуктом? Если спецификация требований определяет компонент более крупной системы, укажите, как это ПО соотносится со всей системой и определите основные интерфейсы между ними.
2.2 Особенности продукта
Перечислите основные особенности продукта или его главные функции.
Также здесь уместно проиллюстрировать основные группы требований и их взаимоотношения, например показать диаграмму потоков данных высшего уровня, диаграмму варианта использования или диаграмму классов,

предполагается, будут работать с вашим продуктом, и опишите их соответствующие

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

доступные разработчикам, и логически обоснуйте каждое положение. Ограничения могут быть

такого рода:
определенные технологии, средства, языки программирования и базы данных, которые следует использовать или избегать;
ограничения, налагаемые операционной средой продукта, например типы и версии установленных Web-браузеров;
обязательные соглашения или стандарты разработки (например, если обслуживать ПО будут клиенты, то они должны указать особенности дизайна и стандарты программирования, которые субподрядчик обязан соблюдать);
обратная совместимость с продуктами, выпущенными ранее;
ограничения, налагаемые бизнес-правилами ;
ограничения, связанные с оборудованием, например требования к срокам, ограничения памяти или процессора, размер, вес, материалы или затраты;
соглашения, связанные с пользовательским интерфейсом существующего продукта, которые необходимо соблюдать при улучшении существующего продукта;
стандартный формат обмена данными, например XML.

исполняемым ПО. В них могут входить руководства для пользователя, онлайн-справка

и обучающие программы. Определите все необходимые форматы, стандарты и средства поставки документации.
2.7 Предположения и зависимости
Предположением (assumption) называется положение, которое считается истинным при отсутствии доказательства или определяющей информации. Проблемы возможны в том случае, если предположение неверны, не находятся в совместном использовании или они изменяются, поэтому определенные предположения можно отнести к группе рисков проекта. Один пользователь спецификации может считать, что продукт будут соответствовать особому стандарту пользовательского интерфейса, тогда как другой предположит нечто совершенно иное. Разработчик может думать, что определенный набор функций написан специально для этого приложения, аналитик— что он будет взят из предыдущего проекта, а менеджер проекта— что предполагается приобрести коммерческую библиотеку функций. Определите все зависимости (dependencies) проекта от внешних факторов, такие, как дату выпуска следующей версии операционной системы или выпуск промышленного стандарта.

Также назовите подразделы с З.х.1 по З.х.З для каждой особенности

системы.
З.х.1 Описание и приоритеты
Кратко опишите особенность системы и укажите, обладает ли она высоким, средним или низким приоритетом. Приоритет являются динамической характеристикой, они могут изменяться в ходе проекта. Если вы используете средство управления требованиями, определите атрибут требований для приоритета
З.х.2 Последовательности ≪воздействие - реакция≫
Перечислите последовательность воздействий, оказываемых на систему (действия пользователей, сигналы внешних устройств и др.), и отклики системы, определяющие реакцию конкретной функции. Эти воздействия соответствуют первоначальным шагам для вариантов использования или внешним системным событиям.
З.х.З Функциональные требования
Перечислите по пунктам детализированные функциональные требования, которые связаны с этой особенностью. Чтобы пользователь мог задействовать эту особенность или реализовать варианты использования, обязательно следует предусмотреть определенные функции ПО. Опишите, как продукт должен реагировать на ожидаемые ошибки, неправильный ввод информации или неверные действия. Присвойте каждому функциональному требованию уникальное имя.

к внешнему интерфейсу определяют оборудование, ПО или элементы баз данных,

с которыми система или компонент должны взаимодействовать...≫
Выработка согласованного решения, касающегося внешнего и внутреннего интерфейса системы, признана наилучшим приемом в области разработки ПО (Brown, 1996).
Вставьте подробные описания компонентов данных и элементов управления интерфейса в словарь данных. В сложной системе с множеством подкомпонентов следует использовать раздельные спецификации для интерфейсов или спецификацию системной архитектуры (Hooks и Farry, 2001). В документацию по интерфейсу можно включить ссылки на материал из других документов. Например, ссылка на спецификацию программного интерфейса другого приложения (API) или на руководство по работе с устройством, где перечислены коды с ошибками, которые устройство может отправить ПО.

системе. Некоторые из них перечислены здесь:
ссылки на стандарты графического интерфейса

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

Детально документируйте детали пользовательского интерфейса, такие, как конфигурации определенных диалоговых окон, в отдельной спецификации пользовательского интерфейса, а не в спецификации требований к ПО. Конечно, добавить еще одну точку зрения на требования полезно, но необходимо подчеркнуть, что эти модели не являются официальными планами экрана. Если в спецификации требований к ПО говорится об улучшении существующей системы, то стоит включить в документ изображения экранов в том виде, как они будут реализованы. Для разработчиков уже заданы ограничения существующей системой, поэтому можно заранее представить, как будут выглядеть измененные, а, возможно, новые экраны.

оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия

данных и элементов управлений между ПО и оборудованием, а также протоколы взаимодействия которые будут использоваться.

4.3 Интерфейсы ПО
Опишите соединения продукта и других компонентов ПО (идентифицированные по имени и версии), в том числе базы данных, операционные системы, средства, библиотеки и интегрированные коммерческие компоненты. Укажите назначение элементов сообщений, данных и элементов управления, обмен которыми происходит между компонентами ПО. Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия между компонентами. Определите данные, к которым будут иметь доступ компоненты ПО. Если механизм предоставления общего доступа к данным должен быть реализован определенным способом, например в качестве глобальной области данных, то укажите его как ограничение.

4.4 Интерфейсы передачи информации
Укажите требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и электронные формы. Определите соответствующие форматы сообщений. Опишите особенности безопасности взаимодействия или шифрования, частоты передачи данных и механизмов синхронизации.

требования, не относящиеся к требованиям к интерфейсу
5.1 Требования к производительности
Укажите

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

возможная реализация предполагаемого нового продукта.
Прототипы позволяют решать три основные

задачи:
Пояснение и завершение процесса формирования требований. В этом случае прототип используется как инструмент уточнения требований, позволяет указать на ошибки в формулировке требований, которые можно исправить без больших затрат до создания реального продукта.
Исследование альтернативных решений. В данном случае прототип используется как инструмент конструирования, который позволяет исследовать различные варианты реализации требований и оценить возможные технические приемы.
Создание конечного продукта. В данном случае прототип используется как инструмент эволюционной или инкрементной модели построения системы.
Концепция новой ИС может быть представлена в виде прототипа (модели). Для этого используются прототипы 1 и 2 типа.

на ранних стадиях процесса разработки.
К прототипам, проясняющим и завершающим

процесс формулировки требований и создания концепции новой ИС, относятся модели TO – BE.
Создание этих моделей является важнейшим этапом в создании системного проекта.
На этом этапе моделируются новые бизнес-процессы и новые информационные потоки, которые появятся в организации в результате внедрения новой информационной системы.
Эти модели строятся на основании утвержденных требований к новой ИС и используются для однозначного понимания нового ИТ - решения заказчиком и исполнителем проекта.

результате формирования требований появились предложения по реорганизации бизнес-процессов.
Контекстная модель:
Название: Отпуск

готовой продукции «Метиз – М».
Цель: Увеличение числа продаж.
Увеличение числа продаж на 50%, уменьшение среднего рабочего времени каждого сотрудника на обслуживание заказчика до 20 минут, уменьшение времени заказчика для оформления заказа не более 1 часа.
Точка зрения: начальник отдела продаж.

заказ.
Выходные данные: обработанный заказ (заказ со статусом «принят» или отказ

от выполнения заказа); документы на оплату и получение; отчеты; закрытие договора; данные для систем «Склад» и «Производство».
Управление: номенклатура и цена, устав, положение, документы системы (нормативные документы предприятия для сопровождения системы продаж).
Механизмы: сотрудник отдела продаж, система продаж.

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

бизнес-процесса (реинжинеринг) в рассматриваемой предметной области.
Действительно, в модели AS-IS бизнес-процесс реализации товара состоял из следующих основных функций: проверка готовности заказа, организация оплаты, организация выдачи, подготовка отчетов.
В новой системе большое значение уделяется приему и размещению заказа (в случае отсутствия готовой продукции на складе). Кроме того, система должна быть интегрирована в общую систему управления предприятием.
Новые функции системы описаны в документе бизнес-требования.
Поскольку все они не могут быть отображены на диаграмме декомпозиции (ограничения инструментария), сгруппируем их следующим образом: прием и размещение заказа, организация оплаты, организация отгрузки, закрытие договора, создание и выдача отчетов.

и изучения бизнес-процессов и объекта информатизации.
Описание и оценку преимуществ и

недостатков разработанных альтернативных вариантов концепции реализации бизнес-процессов и создания новой ИС.
Сопоставимый анализ требований к ИС и вариантов концепции на предмет удовлетворения требований заказчика и пользователей.
Обоснование выбора оптимального варианта концепции и описание постановки задач ИС.
Ожидаемые результаты и эффективность реализации выбранного варианта концепции ИС.
Описание и графическое представление идеальной модели ИС без реальных ограничений реализации.
Ориентировочный план реализации выбранного варианта концепции ИС.
Ориентировочный перечень мероприятий, необходимых для перехода с существующей на новую ИС.
Необходимые затраты ресурсов на разработку, ввод в действие и обеспечение функционирования новой ИС.
Требования, гарантирующие необходимое качество, надежность функционирования и безопасность применения ИС.
Принципы испытаний и приемки новой ИС.
Первичную оценку целесообразности создания новой или модернизированной ИС и разработки системного проекта.