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

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

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

Функциональные требования удобно представлять в виде диаграмм вариантов использования. Вариант использования представляет собой последовательность действий, выполняемых системой, в ответ на события, инициируемые внешним объектом (действующим лицом — актором по терминологии, принятой в ряде публикаций [10]). Такие диаграммы используются в ЛиР-технологии разработки программных проектов [17].

Анализ требований 6. Бизнес-объекты. Бизнес требования. Функциональные требования.

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

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

Модель вариантов использования имеет следующие достоинства:

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

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

13/48 — Что такое требования к ПО? Курс Бизнес-анализ в IT.

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

Диаграммы вариантов использования — один из видов диаграмм UML, предназначенных для моделирования динамических аспектов систем. Это основной вид диаграмм при моделировании поведения системы и требований, предъявляемых к системе. Формулирование требований к системе, по сути, представляет собой составление контракта между ней и теми сущностями, которые находятся вне ее.

Этот контракт декларирует, что система должна делать. Хорошая система выполняет требования точно, предсказуемо и надежно. Удобным инструментом построения диаграмм использования является IBM Rational Software Architect — часть IBM Software Development Platform — набора инструментов, поддерживающих жизненный цикл разработки программных систем.

Продукт IBM Rational Software Architect предназначен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. RSA объединяет в себе функции таких программных продуктов, как Rational Application Developer, Rational Web Developer и Rational Software Modeler, тем самым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам — выполнять разработку J2EE, XML, веб-сервисов и т.д. Следуя принципам RUP, Rational Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как:

• • бизнес-анализ и моделирование (business modeling);
• • управление требованиями (requirements);
• • анализ и проектирование (analysis and design);
• • реализация (implementation).

Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемое™.

Правильно сформулированные функциональные требования должны обладать следующими характеристиками.

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

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

• 3. Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды. Чтобы не придумывать недостижимые положения, нужно обеспечить взаимодействие разработчиков с маркетологами и аналитиками требований на весь период определения требований. Разработчики реально оценят, что можно выполнить технически, а что нет, или что сделать можно, но при дополнительном финансировании. Инкрементальная разработка и подтверждающие концепцию прототипы позволяют проверить осуществимость требования.
• 4. Необходимость. Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним системным требованиям или стандартам. Кроме того, требование должно исходить от лица, которое имеет полномочия на запись положения. Необходимо отследить каждое требование, вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использования, бизнес-правила или другие источники.
• 5. Назначение приоритетов. Каждому функциональному требованию, характеристике или варианту использования необходимо назначить приоритеты, чтобы определить, что нужно для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки.
• 6. Однозначность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Документация должна быть написана просто, кратко и точно, лексика должна быть понятна пользователям. Ясность — цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение.
• 7. Проверяемость. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются.

В 80-х — 90-х годах XX в. для описания функциональных требований широко использовался полуформальный метод Н1РО-диаграмм (Hierarchy plus Input — Process — Output): иерархия плюс ввод — обработка — вывод [11, 12]. ШРО-диаграмма строится для каждой основной требуемой функции. В ней дается обобщенная характеристика входных и выходных данных для этой функции и основных шагов обработки. Для отображения иерархической организации таких функций строится оглавление.

При использовании этого метода диаграммы обычно готовит организация-разработчик, а затем предъявляет их пользователю для проверки. Задача ШРО-диаграмм — дать пользователю наглядное представление о будущем продукте в надежде услышать от него: «Да, я хотел, чтобы программа делала именно это». Важно понимать, что ШРО-диаграммы, так же как и диаграммы вариантов использования, отображают в основном функциональные требования. Другие требования должны быть описаны отдельно.

Источник: studref.com

Консалтинг в области информационных технологий (ИТ-консалтинг)

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

6.7.2. Разработка требований к функциональности информационной системы

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

Разрабатываемые требования к функциональности делятся на две большие группы: общие и требования к функциям.

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

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

1. Функциональная модель бизнес-процесса.
2. Описание бизнес-процесса и функциональные требования к процессу в целом (содержательная часть, в т. ч. цель, задачи, требования к исполнению и контролю, распределение ответственности, входная и выходная информация, требования к безопасности).
3. Перечень и описание функций/процедур бизнес-процесса
4. Описание требований к функциональности ИС по всем функциям/процедурам бизнес-процессов.
5. Список входных и выходных документов.

На основе выявленных требований в дальнейшем разрабатывается техническое задание.

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

6.7.3. Работы при выборе и обосновании продуктового решения

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

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

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

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

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

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

• системы управления ресурсами предприятия (Enterprise Resource Planning, ERP — планирование ресурсов предприятия / Manufacturing Requirement Planning, MRP II — планирование производственных ресурсов/ Material Requirements Planning, MRP — планирование материальных ресурсов);
• системы управления активами и фондами (Enterprise Asset Management, EAM );
• системы управления взаимоотношениями с клиентами (Customer Relationship Management, CRM);
• системы управления цепочками поставок ( Supply Chain Management, SCM );
• системы управления персоналом (Human Resources Management , HRM );
• системы документационного обеспечения управленческой деятельности;
• системы управления эффективностью бизнеса (Business Performance Management , BPM );
• системы интеллектуального бизнес-анализа (Вusiness Intelligence BI);
• системы управления данными об изделии (Product Data Management , PDM ).

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

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

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

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

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

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

В этом случае организацией дается объявление о проведении открытого запроса предложений, либо проводится рассылка информационного письма «Запрос информации» потенциальным поставщикам.

В письме «Запрос информации» кратко дается общая информация о проекте и условиях участия, запрашивается краткая информация о поставщиках, программных продуктах.

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

В состав документа «Запрос предложения», как правило, включают следующую информацию:

1. Общие сведения об организации.
2. Цели организации, задачи, стратегический план (необходимые выдержки).
3. ИТ-стратегию или тактический план (необходимые выдержки).
4. Ожидаемые результаты проекта.
5. Требования к программному продукту, включая требования к функциональности.
6. Требования к поставщику решения.
7. Требования по оформления и документарному составу предложения. Стандартные формы.
8. Критерии и методику оценки предложений.
9. Модель ценообразования.
10. Основные договорные требования / проект договора.
11. Контакты.
12. Сроки и место представления предложений.

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

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

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

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

По результатам исследования, проведенного компаниями SAP и Market-Visio Consulting/ Gartner, организации при выборе поставщика ИТ-решений, в первую очередь, обращают внимание на качество предлагаемых продуктов и услуг. Вторым важным фактором является наличие истории успешных внедрений в организациях данной или схожей отрасли. Третий фактор — квалификация сотрудников ИТ- интеграторов .

При выборе поставщика комплексных программных решений ведущая аналитическая компания Gartner рекомендует использовать следующие критерии оценки:

1. Функциональные возможности.
2. Архитектура: техническая инфраструктура, необходимая для поддержки решения.
3. Устойчивость продукта: оценка в трех измерениях — финансы, структура и рынок.
4. Цена: средняя стоимость приобретения, инсталляции, обновления версий и технической поддержки программного продукта.
5. Сервис и поддержка: уровень технической поддержки, который обеспечивают поставщик и его партнеры.
6. Концепция и видение: прогнозы поставщика относительно тенденций развития отрасли; действия поставщика в плане функциональности и стратегии развития продукта в свете этих прогнозов.

Поставщик оценивается в двух аспектах — стабильность и полнота концепции.

В настоящее время компанией Gartner Inc. запатентована методика «Magic Quadrant» (Магический Квадрант), которая заключается в подготовке отчета с графическим представлением определенного рынка продукции за некоторый период времени. Этот отчет сравнивает компании по набору критериев, разработанных для данного рынка, и отражает мнение исследовательской компании. В «Магическом квадранте» компании оцениваются по полноте видения рынка (completeness of vision) и по способности к практической реализации этого видения (ability to execute). В соответствии с этими критериями системы различных производителей располагаются в четырех квадрантах: «лидеры» ( leaders ), «провидцы» (visionaries), «бросающие вызов» ( challengers ) и «нишевые игроки» (Niche Players). К сектору лидеров компания Gartner Inc. относит поставщиков, которые успешно ведут свою деятельность, имеют четкую концепцию работы на рынке и активно совершенствуют свои возможности для реализации этой концепции и удержания своих лидирующих позиций,

Исследования компании Gartner Inc. предоставляют один из источников информации для проведения сравнительного анализа и не являются окончательной рекомендацией выбирать только того производителя, который оценен как «Лидер».

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

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

Следует отметить, что разработка состава критериев оценки программных продуктов по функциональности зависит от класса, к которому принадлежат рассматриваемые программные решения. Например, один из подходов к сопоставлению ERP-систем по функциональности разработан аналитической компанией Arlington Software Corporation в рамках проекта ERP Evaluation Center.

ERP Evaluation Center является ресурсом компании TEC Group, целью которого является анализ и сравнение, представленных на рынке ERP-систем. Согласно разработанному подходу для оценки функциональности используется дерево критериев, содержащее более 3600 частных критериев. Критерии нижнего уровня входят в критерии более высокого уровня со своими весовыми коэффициентами.

Вершина дерева представляет собой комплексную численную оценку функциональности системы. В рамках проекта разработана таблица весов критериев и программные средства для решения многокритериальных задач. Помимо критериев функциональности для ERP-систем разработаны иерархии частных критериев для отдельных систем: CRM (более 1100 критериев), PLM (Product Lifecycle Management -управление жизненным циклом продукции, более 1300 критериев), SCM (более 2200 критериев), BI (более 1300 критериев).

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

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

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

Стандартное аппаратное и программное обеспечение, информационные системы имеют свои особенности как предмет конкурса.

Выделяют следующие особенности стандартного аппаратного и программного обеспечения как предмета конкурса:

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

• обеспечивающие возможность модернизации аппаратного и программного обеспечения;
• по обеспечению расходными материалами;

Особенности информационной системы как предмета конкурса определяются следующими положениями:

• необходимостью подготовки специальных требований:

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

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

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

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

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

Источник: intuit.ru

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

Обоснование необходимости разработки требований к ИС

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

• · Правильность понимания задач системы;
• · Системный подход к разработке требований;
• · Достоверное понимание всех желаний заказчика;
• · Уменьшение количества доработок, возникающих в будущем;
• · Уменьшение затрат на поддержку и обслуживание;
• · Точное следование расписанию внедрения проекта;
• · Повышение качества итогового проекта;
• · Повышение скорости разработки.

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

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

• · Бизнес-требования — цели системы высшего уровня, такие требования обычно определяются заказчиками.
• · Требования пользователей — цели и задачи, решаемые пользователями с помощью конечной системы.
• · Функциональные требования — описание ожидаемого поведения системы, описывая все возможные ситуации. Традиционно содержат положения с формулировкой «должен». Например, система должно отображать отчеты по клиентам.
• o К функциональным требованиям также относятся системные требования — описание технических параметров аппаратуры для эффективного использования устанавливаемого программного обеспечения.
• · Нефункциональные требования определяют атрибуты качества разрабатываемой системы. Нефункциональные требования описывают характеристики конечной системы, важные для пользователей. К ним могут относиться такие атрибуты, как производительность, простота использования, минимальное количество сбоев, надежность и т.д. [2]

Рисунок 7 показывает уровни требований с учетом их связи между различными группами.

Рис.7 Взаимосвязь уровней требований к ИС[2]

Альтернативный вариант классификации требований, который широко используется на практике, был разработан Робертом Грэйди из Hewlett-Packard. Он имеет название «FURPS+». Эта аббревиатура расшифровывается следующим образом:

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

· Usability, удобство использования

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

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

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

Например, локализация, совместимость с другими системами, ремонтопригодность и конфигурироемость.

• · «+» возможные дополнительные ограничения:
• o проектирования;
• o разработки;
• o на интерфейсы;
• o физические. [3]

Источник: studwood.net