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

Определение понятия требования

В IEEE

Standard Glossary of Software Engineering Terminology (1990) [2.1] данное понятие трактуется шире. Требование — это:

IEEE (Institute of Electrical and Electronics Engineers) — институт инженеров по электротехнике и электронике, http://www.ieee.org — международная некоммерческая ассоциация специалистов в области техники, делит с МЭК (http://www.iec.ch/) мировое лидерство в области разработки стандартов по радиоэлектронике и электротехнике. IEEE объединяет более 400 тыс. членов из 170 стран, в том числе более 100 тыс. студентов.

IEC (International Electrotechnical Commission) — международная электротехническая комиссия (МЭК), http://www.iec.ch. МЭК — некоммерческая организация, наряду с IEEE (http://www.ieee.org)- признанный мировой лидер в области создания международных стандартов в сфере электрики, электронники и смежных технологий, в том числе — в области информационных технологий. Под эгидой организации сотрудничают более 10 000 специалистов. Некоторые из разработанных стандартов созданы совместно с ISO.

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

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

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

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

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

WBS Work Breakdown Structure — иерархическая структура работ. Согласно PMBOK, WBS — это ориентированная на результаты (предметы поставки) иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и получения необходимых результатов. С ее помощью структурируется и определяется все содержание проекта.

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

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

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

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

Поделиться:
Нет комментариев

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

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.