Блог

Основные требования к программному обеспечению

Требования к программным продуктам

IEEE Standard Glossary of Software Engineering Terminology определяет требования как:

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

Какие требования бывают

Требования к ПО состоят из трех уровней — бизнес-требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования. Модель на рис. ниже иллюстрирует способ представления этих типов требований.

Бизнес-требования(business requirements)

Бизнес-требования(business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Мне нравится записывать бизнес-требования в форме документа об образе и границах проекта, который еще иногда называют уставом проекта (project charter) или документом рыночных требований (market requirements document). Определение границ проекта представляет собой первый этап управление общими проблемами увеличения объема работ.

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

Требования пользователей (user requirements) описывают цели и задачи, которые пользователям даст система. К отличным способам представления этого вида требований относятся варианты использования, сценарии и таблицы «событие — отклик». Таким образом, в этом документе указано, что клиенты смогут делать с помощью системы.

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

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы.

Системные требования (system requirements)

Системные требования (system requirements) — это высокоуровневые требования к продукту, которые содержат многие подсистемы. Говоря о системе, мы подразумеваем программное обеспечение или подсистемы ПО и оборудования. Люди — часть системы, поэтому определенные функции системы могут распространяться и на людей.

Бизнес-правила (business rules)

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

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

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

Характеристика продукта (feature)

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

Какими характеристиками должны обладать хорошие требования?

Характеристики качества превосходных требований:

Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. То есть оно должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Если вы понимаете, что данных определенного рода не хватает, используйте пометку «TBD» (to be determined — необходимо определить) на полях как стан-
дартный флаг для выделения такого места. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.

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

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

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

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

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

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

Какими характеристиками должны обладать спецификации требований?

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

Полнота. Никакие требования или необходимые данные не должны быть пропущены.

Согласованность. Согласованные требования не конфликтуют с другими требованиями такого же типа или с высокоуровневыми пользовательскими, системными или бизнес-требованиями. Несогласованность документов следует устранить до начала процесса разработки. Вы не всегда знаете, какое именно положение некорректно (если какое-то некорректно), пока не выполните исследование. Рекомендуется записывать автора каждого требования, чтобы узнать, кто его высказал, если конфликт все-таки будет обнаружен.

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

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

Требования к программному обеспечению

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

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

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

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

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

Виды требований по уровням

  • Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
  • Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
  • Функциональные требования — охватывают предполагаемое поведение системы, определяя действия, которые система способна выполнять [источник не указан 104 дня] . Описывается в системной спецификации (англ.system requirement specification , SRS).

Виды требований по характеру

  • Функциональный характер — требования к поведению системы
    • Бизнес-требования
    • Пользовательские требования
    • Функциональные требования
  • Нефункциональный характер — требования к характеру поведения системы
    • Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
    • Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и ПО.
    • Атрибуты качества
    • Внешние системы и интерфейсы
    • Ограничения

Источники требований

  • Федеральное и муниципальное отраслевое законодательство (конституция, законы, распоряжения)
  • Нормативное обеспечение организации (регламенты, положения, уставы, приказы)
  • Текущая организация деятельности объекта автоматизации
  • Модели деятельности (диаграммы бизнес-процессов)
  • Представления и ожидания потребителей и пользователей системы
  • Журналы использования существующих программно-аппаратных систем
  • Конкурирующие программные продукты

Характеристики качественных требований

Характеристики качественных требований по-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными:

Методы выявления требований

  • Интервью, опросы, анкетирование
  • Мозговой штурм, семинар
  • Наблюдение за производственной деятельностью, «фотографирование» рабочего дня
  • Анализ нормативной документации
  • Анализ моделей деятельности
  • Анализ конкурентных продуктов
  • Анализ статистики использования предыдущих версий системы

Проверка требований

Все требования должны быть поддающимися проверке. Наиболее общепринятая методика проверки — тесты. Если проверка тестами невозможна, тогда должен использоваться другой метод проверки (анализ, демонстрация, осмотр или обзор дизайна).

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

Нефункциональные требования, которые являются неподдающимися проверке на программном уровне, все равно должны быть сохранены как документация намерений клиента; Такие требования к продукту могут быть преобразованы в требования к процессу. Например, нефункциональное требование, чтобы ПО не содержало «потайных ходов», может быть удовлетворено заменой на требование использовать парное программирование. Сложные требования безопасности авиационного программного обеспечения могут быть удовлетворены следованием процессу разработки DO-178B (англ.) .

Анализ требований

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

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

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

Документирование требований

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

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

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

За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы или методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

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

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

  • Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2
  • Основы программной инженерии (по SWEBOK). Требования (рус.) (перевод SWEBOK с замечаниями и комментариями от Сергея Орлика и Юрия Булуя)
  • Краткий курс в управление требованиями (+ аудио) (рус.)
  • Статьи с ответами на вопросы о системном анализе
Другие публикации:  Перечень документов на гражданство 2019

Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл

Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)

CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML

Wikimedia Foundation . 2010 .

Смотреть что такое «Требования к программному обеспечению» в других словарях:

требования к программному обеспечению — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software requirement … Справочник технического переводчика

ГОСТ Р 53195.4-2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению — Терминология ГОСТ Р 53195.4 2010: Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 4. Требования к программному обеспечению оригинал документа: 3.1 анимация (animation): Имитация работы программного… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 52980-2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению — Терминология ГОСТ Р 52980 2008: Системы промышленной автоматизации и их интеграция. Системы программируемые электронные железнодорожного применения. Требования к программному обеспечению оригинал документа: 3.1 автоматическая локомотивная… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.654-2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения — Терминология ГОСТ Р 8.654 2009: Государственная система обеспечения единства измерений. Требования к программному обеспечению средств измерений. Основные положения оригинал документа: 3.18 алгоритм хэширования: Алгоритм, который сжимает… … Словарь-справочник терминов нормативно-технической документации

МИ 2891-2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений — Терминология МИ 2891 2004: Рекомендация. ГСОЕИ. Общие требования к программному обеспечению средств измерений: Данные измерительная информация, представленная в виде, пригодном для передачи, интерпретации или обработки. Определения термина из… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 8.674-2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями — Терминология ГОСТ Р 8.674 2009: Государственная система обеспечения единства измерений. Общие требования к средствам измерений и техническим системам и устройствам с измерительными функциями оригинал документа: вид средства измерений:… … Словарь-справочник терминов нормативно-технической документации

МИ 3372-12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования — Терминология МИ 3372 12: Рекомендация. Государственная система обеспечения единства измерений. Магистральный нефтепродуктопровод. Системы измерений количества и показателей качества нефтепродуктов. Общие технические и метрологические требования:… … Словарь-справочник терминов нормативно-технической документации

СА 03-002-05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования — Терминология СА 03 002 05: Стандарт ассоциации. Системы мониторинга агрегатов опасных производственных объектов. Общие технические требования: 2.1. Агрегат : совокупность механически соединенных механизмов, узлов, машин и конструкций, работающих… … Словарь-справочник терминов нормативно-технической документации

П ССФЖТ 45/ИСО 9001-2003: Системы менеджмента качества. Требования — Терминология П ССФЖТ 45/ИСО 9001 2003: Системы менеджмента качества. Требования: 3.7 запись: Документ, содержащий достигнутые результаты или свидетельства осуществленной деятельности (ГОСТ Р ИСО 9000). Определения термина из разных документов:… … Словарь-справочник терминов нормативно-технической документации

ГОСТ Р 51904-2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию — Терминология ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию оригинал документа: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации

Основные требования к программному обеспечению

Определение требований к программному обеспечению

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

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

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

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

Можно определить следующие шаги рабочего процесса определения требований*:

Перечисление возможных требований;

Осознание контекста системы;

Определение функциональных требований;

Определение нефункциональных требований.

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

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

состояние предложения (например, предложено, одобрено, включено в план, утверждено);

трудоемкость в человеко-часах или стоимость реализации;

приоритет (например, критический, важный или вспомогательный);

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

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

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

Моделирование предметной области;

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

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

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

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

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

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

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

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

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

Основные требования к программному обеспечению

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

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

Документ или пакет?

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

От видения к SRS

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

Нам требуется уже набор, или пакет, артефактов, который полностью описывает наблюдаемое поведение системы, то есть пакет, указывающий, какие возможности предоставляет система и как они реализуются. Это и называется пакетом SRS.

Динамический артефакт

Пакет SRS — это не застывший фолиант, напечатанный ради совместимости с ISO 9000 и затем поставленный на полку. Это живой объект, с которым работают разработчики проекта. Он служит основой для коммуникации между разными группами — между самими разработчиками, а также разработчиками и пользователями или заинтересованными лицами. Формально или неформально, он представляет своего рода договор между сторонами, если что-либо не отражено в пакете SRS, то разработчики не должны над этим работать. А если что-либо отражено в пакете SRS, то они полностью отвечают за реализацию этой функциональности.

Стандартный документ руководителя проекта

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

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

Определение функциональных требований

Определение нефункциональных требований

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

1.1 Предположения и нерешенные вопросы

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

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

Другие публикации:  Требования к помещению медицинского центра

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

Все нерешенные вопросы, которые могут помешать успешному ходу проекта

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

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

1.2 Расположение организации заказчика

Отразите в документе расположение учреждений заказчика.

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

2 Заданные условия

2.1 Заранее выбранные пакеты приложений?

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

  • Тип рабочих станций
  • Методы соединения
  • Тип процессора и запоминающего устройства с прямым доступом (DASD)
  • Программа управления системой
  • Организация, размещение данных и управление
  • Язык программирования
  • Пакетные интерфейсы
  • Взаимосвязь процессов и данных
  • Бизнес-логика
  • Проект пользовательского интерфейса
  • Параметры производительности и обеспечения готовности
  • Архитектура и форматы печати (например, PostScript, PCL, IPDT)
  • Поддержка национальных языков (NLS)

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

  • поставщика пакета
  • внешних консультантов
  • специально обученных участников коллектива

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

2.2 Прочие заданные условия

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

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

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

Повлияют ли эти заданные условия на новую систему? Если система будет работать на существующем процессоре, в операционной системе или сети, повлияют ли на нее особенности существующей платформы и нагрузки?

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

Какие механизмы защиты используются задачами? Примите во внимание эти данные и сравните их с требованиями новой системы.

Каковы параметры обеспечения готовности существующей системы?

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

2.3 Специальное аппаратное обеспечение

Указана ли в требованиях необходимость использования какого-либо специального аппаратного обеспечения?

Это может быть отражено в общих терминах (система должна поддерживать высокоскоростной графопостроитель) или в более конкретных (поддержка банкоматов корпорации Panda). Задокументируйте следующее:

  • Предварительные требования к аппаратному и программному обеспечению
  • Поставщики и их службы поддержки
  • Поддержка национальных языков (NLS)
  • Криптография
2.4 Существующие данные

Указана ли в требованиях необходимость использования существующих данных? Если да, отразите это в проекте системы. Задокументируйте следующее:

  • В каких системах расположены данные
  • Структура данных — простой файл или база данных
  • Объем данных
  • Пользователи и системы, работающие с этими данными
  • Замечания по готовности (например, периоды недоступности данных из-за обслуживания базы данных или пакетных задач)
  • Возможность копирования или перемещения данных
3.1 Техническая архитектура / стратегический план

Имеет ли клиент техническую архитектуру, стратегический план ИТ или эквивалентный набор стандартов?

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

  • Техническая платформа предприятия
  • Техническая инфраструктура предприятия
  • Технологическая архитектура

В технической архитектуре могут быть указаны следующие моменты:

  • Число и возможность использования вычислительных центров
  • Сетевая инфраструктура глобальной сети предприятия (WAN)
  • Локальные сети подразделений (LAN)
  • Развитость служб клиент-серверной инфраструктуры (промежуточное программное обеспечение)

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

  • Методы разработки новых приложений
  • Принятый набор поддерживаемых продуктов, например:

· аппаратное обеспечение
· программное обеспечение управления системой
· прикладное программное обеспечение общего назначения, например, офисное
· справочная служба
· правила защиты

  • Архитектура подсистемы печати

Это список может быть очень обширным, а его элементы могут быть регламентированы очень строго или вообще не регламентированы.

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

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

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

3.2 Сетевая архитектура

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

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

Какие функции соединения поддерживаются текущей инфраструктурой сети.

Какие стандарты связи (SNA, OSI, TCP/IP) применяются для поддержки этих функций.

Какие поддерживаются интерфейсы программирования.

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

  • Доступ к данным серверов баз данных в сети должен осуществляться клиентами по протоколу какой-либо конкретной базы данных.
  • Логика презентации должна быть реализована в клиенте, а логика доступа к данным — только не центральном хосте.
3.3 Стратегии соединений

Есть ли у клиента заданные стратегии соединений?

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

Задокументируйте все стратегии относительно следующих факторов:

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

Есть ли у клиента другие правила, стратегии или стандарты, не отраженные в его требованиях? Например:

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

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

Разрешается ли пользователям или отделам добавлять и/или разрабатывать собственные программы:

  • на рабочих станциях
  • на серверах (особенно в связи с использованием дисковой памяти)

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

4.1 Единицы измерения

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

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

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

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

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

4.2 Количественные показатели

Для каждой из сущностей из пункта 4.1 задокументируйте количественные показатели, например:

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

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

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

5 Обеспечение готовности

5.1 Советы по обеспечению готовности

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

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

При формулировке требований примите во внимание следующее:

  • Вместо того, чтобы формулировать глобальные требования для системы в целом, укажите требования по обеспечению готовности на уровне ее составных частей (например, для отдельных процессов, групп пользователей, групп данных и пр.) . При этом у проектировщика будут развязаны руки в подходах к обеспечению потребностей пользователей. Это особенно важно для систем, которые должны работать в непрерывном режиме почти всегда.
  • Формулировка «Система должна работать 24 часа в сутки, чтобы пользователи в США и Китае могли работать» оставляет проектировщику гораздо меньше вариантов, чем формулировка «Пользователи из Нью-Йорка должны иметь возможность выполнять транзакции со своими данными с 7 до 19 часов по времени Нью-Йорка, и пользователи из Гонконга должны иметь возможность выполнять транзакции со своими данными с 7 до 19 часов по времени Гонконга». Во втором варианте у проектировщика появляется возможность спланировать обслуживание одного из компонентов системы в отведенные для этого часы, в то время как компонент для другого часового пояса будет продолжать работать.
  • В приложении банкомата может быть очень важным обеспечить возможность выдачи денег в 3 часа утра в понедельник, но возможность получения в это время справки об остатке на счете может быть менее важной.
  • Разделите желательные и обязательные требования по обеспечению готовности. Например: «Банкомат ДОЛЖЕН круглосуточно принимать депозиты и выдавать наличные. ЖЕЛАТЕЛЬНО, чтобы банкомат мог выдавать сведения об остатке на счете круглосуточно, однако допустимы кратковременные периоды недоступности этой функции, которые ДОЛЖНЫ длиться не более 10 минут и иметь место только от 3:00 до 4:00 утра».
  • Если влияние какого-либо требования на способность пользователей выполнять свои бизнес-задачи не прослеживается явно, то скорее всего это требование не стоит относить к требованиям по обеспечению готовности системы.
  • Требования по обеспечению готовности, которые лишь косвенным образом влияют на возможности пользователей (например, «Контрольная система сообщений должна работать непрерывно»), не будут столь же критичны, как те, которые влияют непосредственно («Банкоматы должны уметь выполнять то-то и то-то»).
Другие публикации:  Договор разработке сайтов
5.2 Запланированное рабочее время

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

Если группы пользователей относятся к разным часовым поясам (как Нью-Йорк и Гонконг), считайте их разными группами пользователей.

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

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

Какие изменения в часах обслуживания можно предположить в течение времени жизни приложения?

5.3 Стоимость простоя системы

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

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

  • Краткие периоды недоступности системы или замедленный ответ в рабочее время. Определите, что такое «краткие периоды» и «замедленный ответ» для этого конкретного приложения (см. «Критерии производительности бизнес-процесса»)
  • Различные более длительные периоды отказа в указанные часы (минута, несколько минут, полчаса, час, три часа и т.д.)
  • Более длительные периоды (смена, день, несколько дней) .
  • Сделайте это и для процессов, которые не связаны прямо с группами пользователей (например, суточный клиринг чеков).

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

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

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

Как в течение времени эксплуатации системы будет меняться влияние отключения системы на сумму убытков?

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

  • Рабочая функция 1 Чтение и обновление записи об ассортименте.
  • Запасная функция 1 Ввод записи об ассортименте и постановке ее в очередь для будущего обновления.
  • Рабочая функция 2 Чтение текущего остатка на счете заказчика.
  • Запасная функция 2 Чтение остатка на счете заказчика из другого источника, возможно, не самых последних данных.
  • Рабочая функция 3 Обновление дневника в компьютере.
  • Запасная функция 3 Обновление печатной копии дневника.

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

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

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

Определите Критерии готовности и восстановления, которые должны быть применимы к «штатным» ситуациям.

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

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

  • Процент отказов, восстановленных в течение заданного времени
  • Максимальное время в течение недели/месяца/года, когда пользователь не может выполнять какие-либо функции

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

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

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

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

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

Рассмотрите «форс-мажорные» ситуации, такие как длительный выход из строя всего компьютерного оборудования. Если они возможны, каковы должны быть критерии восстановления?

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

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

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

Какие изменения в требованиях к восстановлению после аварии ожидаются в течение времени эксплуатации приложения?

5.6 Прочие замечания по обеспечению готовности

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

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

a. Выполнять запросы, но не обновлять при этом данные?

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

2. При отказах, приводящих к необходимости восстановления данных, что будет важнее:

c. Восстановить работу как можно скорее, даже если при этом данные будут не самыми свежими? Или

d. Восстановить текущее состояние данных, даже если при этом система будет выключена дольше?

3. Должны ли запросы пользователей «приниматься в обработку» на время отказа, или пользователь сможет потом повторить запрос после восстановления работы?

4. Есть ли прочие факторы, которые могут повлиять на доступность системы (например, бизнес-правило, указывающее, что процесс A не может быть доступным пользователям, если недоступен процесс B)?

Могут ли эти факторы изменяться со временем?

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

6.1 Требования по защите

1. Определите данные, которые необходимо защищать

2. Определите виды угроз, которым могут быть подвержены данные:

  • Случайное повреждение или уничтожение
  • Намеренное повреждение или уничтожение
  • Промышленный шпионаж
  • Мошенничество
  • Взлом
  • Вирусы

1. Определите угрозы физическим данным:

  • Кража компонентов
  • Несанкционированный доступ к оборудованию
  • Физическая безопасность пользователей

2. Определите людей, которые могут быть источником опасности:

  • Персонал центра данных
  • Прочие специалисты ИТ (например, разработчики)
  • Прочие сотрудники организации
  • Посторонние личности

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

  • Доступ к системе
  • Шифрование данных
  • Возможность аудита

4. Есть ли какие-либо общие положения, например, акты о свободе информации, которые могут повлиять на проектирование защиты системы?

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

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

1. Перечислите объекты, физические и логические, для которых требуется защита.

2. Определите степень открытости объекта. Например:

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

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

3. Определите все угрозы, связанные со средой. Например:

  • Недовольные сотрудники
  • Неправомочные сотрудники
  • Открытые терминальные сеансы в общедоступных местах
  • Хакеры
  • Подслушивающие устройства
  • Потеря оборудования (например, утеря ноутбука)

4. Для каждого объекта определите угрозы и свяжите их с разными возможностями доступа.

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

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

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

  • Секретная военная система
  • Система обращения денег
  • Система, в которой хранится конфиденциальная личная информация

Если к защите системы предъявляются особые требования, то к проектированию этих аспектов может потребоваться привлечь специалиста в области защиты.

7 Удобство работы

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

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

Для достижения этой цели лучше всего сравнить систему с имеющимися альтернативами. Будет разумно ожидать от системы, что она будет существенно удобнее в работе, чем ее альтернативы. Эти альтернативы могут быть следующими:

  • Существующие ручные процедуры.
  • Действующие системы.
  • Конкурирующие продукты.
  • Ранние версии системы.

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

Ниже приведены примеры общих требований удобства работы:

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

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

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

© Copyright IBM Corp. 1987, 2006. Все права защищены..