Про требования и понятие информационной системы

Мы знаем, что есть вот такая шикарная диаграмма:


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

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

Почему? Попытаюсь объяснить.

Знать эту диаграмму мало. Дело в том, что требования представляют собой текстовую / графическую модель проектируемой информационной системы (ИС). Помня, какие виды требований бывают, но не помня, что такое информационная система, довольно проблематично сформулировать все требования, которые необходимы для того, чтобы их совокупность стала моделью проектируемой ИС.

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

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

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

Комментарии

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов

Драйв