double arrow

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

Требования к каналам продаж

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

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

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

Эксплуатационные требования

  • Требования к производительности
  • Требования к объемам информации
  • Требования к нагрузочному тестированию
  • Требования к условиям эксплуатации
  • Требования к доступности системы

Следующий уровень – пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы. Эти требования часто представляют в виде вариантов использования (Use Cases). На втором уровне выделяют также нефункциональные требования – Бизнес-правила и Атрибуты качества.

Бизнес-правила (Business Rules) – связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами, учетными практиками, алгоритмами вычислений и т. д. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос "кто будет осуществлять конкретный вариант, сценарий использования" или диктуют появление некоторых функциональных требований.

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

· Usability (Применимость) – удобство использования

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

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

· Supportability (Эксплуатационная пригодность)

Третий уровень требований – функциональный (functional requirements). На этом уровне определяются функциональные и системные требования, внешние интерфейсы и ограничения.

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

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

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

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

Источниками требований являются:

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

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

· Текущая организация деятельности объекта автоматизации

· Модели деятельности (диаграммы бизнес-процессов)

· Представления и ожидания потребителей и пользователей системы

· Журналы использования существующих программно-аппаратных систем

· Конкурирующие программные продукты.

Характеристиками качественных требований являются следующие [10]:

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

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

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

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

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

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

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

Основными методами выявления требований являются:

· Интервью, опросы, анкетирование

· Мозговой штурм, семинар

· Наблюдение за производственной деятельностью, «фотографирование» рабочего дня

· Анализ нормативной документации

· Анализ моделей деятельности

· Анализ конкурентных продуктов

· Анализ статистики использования предыдущих версий системы

Для документирования требований используется Спецификация программного обеспечения (SRSSoftware Requirements Specification). Спецификацию программного обеспечения нельзя путать с техническим заданием, частью которого она является. При составлении спецификации следует придерживаться стандарта IEEE 830‑1998 [10, 16, 17]. Имеется перевод стандарта на русский язык [18].

Так как формирование требований – сложный процесс, который осуществ­ляется на протяжении всего проекта, то возникло управление требованиями [19] (requirements management) — процесс, включающий идентификацию, выяв­ле­ние, документацию, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Для управления требованиями известны специальные системы, например, IBM Rational RequisitePro [20].


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



Сейчас читают про: