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

Обновлено: 02.07.2024

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Концепция программы (Vision) [источник не указан 186 дней] (англ.Software Requirements Specification, SRS )

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

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

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

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

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

    См. также

    Литература

    • Карл И. Вигерс. Разработка требований к программному обеспечению. — Русская редакция, 2004. — ISBN 5-7502-0240-2

    Ссылки

    Кент Бек • Гради Буч • Фред Брукс • 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 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации

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

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

    Итак, в основном требования к программному обеспечению – это

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

    • Типы требований
    • Другие источники требований
    • Как анализировать требования
    • Атомный
    • Однозначно идентифицировано
    • Полный
    • Последовательный и однозначный
    • Прослеживаемый
    • Приоритет
    • Проверяемый
    • Заключение

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

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

    Добавить биллеров;Имя поставщика коммунальных услуг. ;Номер клиента отношений. ;Автоматические платежи - Да / Нет. ;Оплатить весь счет - Да / Нет. ;Автоматический лимит платежей - не платить, если счет превышает указанную сумму.

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

    Другие источники требований

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

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

    Вывод : чем конкретнее требование, тем лучше.

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

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

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

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

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

    Это определение неидеально. Потому что есть требования, которые пользователь явно не высказывает, например, работа системы в режиме 24/7, или пользователь высказал какое-нибудь пожелание, но оно не было реализовано. Особый случай: требование высказано в устной форме. На мой взгляд, если требование не зафиксировано в письменном виде, то оно не существует.

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


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

    • Бизнес-требования. Что система система должна делать с точки зрения бизнеса. Слово "бизнес" в данном контексте ближе к слову "заказчик". Пример бизнес-требования: промо-сайт, привлекающий внимание определенной аудитории к определенной продукции компании.
    • Пользовательские требования – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). Иначе говоря, пользовательские требования - это что может сделать пользователь: зарегистрироваться, посмотреть определенную информацию, пересчитать данные по определенному алгоритму и прочее.
    • Функциональные требования – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований. Другими словами, что будут делать разработчики, чтобы выполнить пользовательские требования.

    В группу функциональных требований относят и системные требования. Эти характеристики могут описывать требования как к аппаратному обеспечению (тип и частота процессора, объём оперативной памяти, объём жесткого диска), так и к программному окружению (операционная система, наличие установленных системных компонентов и сервисов и т. п.). Обычно такие требования составляются производителем или автором ПО. Например, для игры это могут быть требования такого типа: видеокарта - объём памяти от 64 Мб, совместимость сDirectX 9.0b и новейшие драйвера. Для сайта: ОС - Windows не ниже XP, браузеры IE не ниже 7.0 и так далее.

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

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

    • Бизнес-правила. Они определяют почему система работать должна именно так, как написано. Это могут быть ссылки на законодательство, внутренние правила заказчика и прочие причины. Часто упускают этот раздел и получается, что некоторые системные решения выглядят нетипичным и совсем неочевидными. Например, многие табачные компании и компании, производящие алкоголь требуют постоянного доказательства того, что промо-сайтами пользуются люди, достигшие определенного возраста. Это бизнес-правило (подтверждение возраста) возникает по требованию этических комитетов заказчика, хотя и несколько противоречит маркетинговым целям и требованиям по usability.
    • Внешние интерфейсы. Это не только интерфейсы пользователя, но и протоколы взаимодействия с другими системами. Например, часто сайты связаны с CRM системами. Особенности протокола взаимодействия "сайт-CRM" также относятся к нефункциональным требованиям.
    • Атрибуты качества. Атрибуты касаются вопросов прозрачности взаимодействия с другими системами, целостности, устойчивости и т.п. К таким характеристикам относятся:
      • легкость и простота использования (usability)
      • производительность (performance)
      • удобство эксплуатации и технического обслуживания (maintainability)
      • надежность и устойчивость к сбоям (reliability)
      • взаимодействия системы с внешним миром (interfaces)
      • расширяемость (scalability)
      • требования к пользовательским и программным интерфейсам (user and software interface).
      • Ограничения – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, . ). Ограничения часто основываются на бизнес-правилах.

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

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

      Все вышесказанное относится только к дисциплине "Управление требованиями" в рамках методологии RUP. В рамках ГОСТ и определения требований другие и сами требования разбиваются на совершенно другие группы.

      Функциональные, нефункциональные требования и характеристики продукта. UseCase. Классификация RUP. Разработки IEEE, ГОСТ.

      Основные этапы разработки программного обеспечения:

      Анализ - определение процесса разработки ПО

      Конструирование - описание целевого программного продукта

      Программирование - проектирование продукта

      Тестирование - тестирование частей программного продукта

      Отладка - интеграция частей и тестирование продукта в целом

      Развертывание - сопровождение продукта, обучение пользователей

      Л.Новиков в русской редакции нотации RUP [2.9] приводит следующее определение: "Требование - это условие или возможность, которой должна соответствовать система".


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

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

      3. документированное представление условий или возможностей для пунктов 1 и 2.

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

      Классификация требований

      Существует значительное количество различных методов классификации требований [2.2-2.7], наиболее существенные из которых будут рассмотрены в лекции.

      Требования к продукту и процессу

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

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


      1. регламентация процесса Заказчиком позволяет снизить его риски;

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

      1. Разработчик представляет Заказчику согласованный план работ c детализацией (WorkBreakdownStructure - WBS) с точностью до конкретных исполнителей.

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

      3. Все управленческие и проектные артефакты, исходные коды и тестовые примеры размещаются в режиме online в интегрированной среде разработки Rational ClearCase с возможностью для Заказчика осуществления online-мониторинга на базе web-технологий.

      Уровни требований

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

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


      • На верхнем уровне представлены так называемые бизнес-требования (business requirements). Примеры бизнес-требования: система должна сократить срок оборачиваемости обрабатываемых на предприятии заказов в три раза. Бизнес-требования обычно формулируются топ-менеджерами, либо акционерами предприятия.

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

      • Третий уровень - функциональный (functional requirements). Пример функциональных требований (или просто функций) по работе с электронным заказом: заказ может быть создан, отредактирован, удален и перемещен с участка на участок.

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

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

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

      Существуют различные трактовки понятия "Системные требования" (system requirements).

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

      INCOSE (International Council on Systems Engineering) дает более детальное определение системы: "комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы". Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.

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

      Функциональные, нефункциональные требования и характеристики продукта

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

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

      Use case - вариант использования, прецедент. Данный термин был введен в обиход программной инженерии шведским учёным Айваром Якобсоном (Ivar Hjalmar Jacobson) и по сей день является одной из наиболее позитивных абстракций в области создания требований к программному обеспечению. Согласно нотации UML 2.4.1 (http://www.omg.org/spec/UML/2.4.1/), прецеденты являются средством для определения требуемых использований системы. Как правило, они применяются для извлечения требований к системе, то есть, того, что система предполагает делать. Основными понятиями, связанными с вариантами использования являются акторы, прецеденты, и объект. Объектом является рассматриваемая система, в которой применяются прецеденты. Пользователи и любые другие системы, которые могут взаимодействовать с объектом, представлены в качестве акторов. Акторы всегда моделируют сущности, находящиеся за пределами системы. Требуемое поведение объекта задается одним или несколькими вариантами использования, которые определяются в соответствии с потребностями акторов. Строго говоря, термин "вариант использования" относится к типу прецедента. Экземпляр прецедента относится к проявлению поведения, соответствующего типу прецедента. Такие случаи, как правило, описывается через спецификацию взаимодействий.

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


      • Внешние интерфейсы (External Interfaces),

      • Атрибуты качества (Quality Attributes),

      • Ограничения (Constraints).

      • Применимость,

      • Надежность,

      • Производительность,

      • Эксплуатационная пригодность,

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

      Характеристики продукта. К.Вигерс [2.2] формулирует характеристику, "фичу" (feature), как набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.

      Существует и более общий взгляд на данное понятие [2.9]: "features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта".

      С.Орлик в [2.6] отмечает, что "с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными".

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

      Классификация RUP

      В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].


      • Functionality (Функциональность)

      • Usability (Применимость)

      • Reliability (Надежность)

      • Performance (Производительность)

      • Supportability (эксплуатационная пригодность).

      • ограничения проекта,

      • требования выполнения,

      • требования к интерфейсу,

      • физические требования,

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

      • требования к лицензированию,

      • требования к документированию.

      • ограничения проектирования (design);

      • ограничения разработки (implementation);

      • ограничения на интерфейсы (interface);

      • физические ограничения (physical).

      Подробно описана в работе Роберта Грейди.

      Методологии и стандарты, регламентирующие работу с требованиями

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

      Читайте также: