Черный ящик и его рассмотрение

chya

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

  • Потребности - требования к надсистеме.
  • Требования - описывают то, что должна делать система.
  • Ограничения- требования к целевой системе.

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

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

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

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

 Рассмотрим пример работы с заказчиком, которому необходимо создать систему учёта заявок, которая:

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

В двух пунктах описанных выше указаны требования к системе.

Далее мы начинаем рассуждать: если наша система предполагает отдельную покупку лицензии под каждую учетную запись, то на какое количество она будет рассчитана? Если система предполагает отсутствие масштабируемости - т.е. заранее известно количество пользователей, которые могут работать в системе и т.д.
Т.е. у нас возникает такой параметр, как масштабируемость системы, что является нефункциональным требованием в ИТ, и …..

image-28

.… далее мне необходимы комментарии :)


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

Получается, если мы учитываем при создании системы только требования, потребности и ограничения для удовлетворения текущих интересов заказчика, то фактически он (как показывает мой небольшой опыт), никогда не будет доволен. Т.е. его интерес будет удовлетворен на непродолжительный срок, через полгода он придет и скажет:
"-Ваша система не работает, потому что вместо 15 человек, теперь в ней работает 40. Из-за чего она стала медленной, а те отчеты, которые мы делали ранее уже не дают корректной оценки работы. Что вы мне за ерунду продали!"

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

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

image-29

Итак знатоки, внимание вопрос!
Как блондинке из ИТ интерпретировать нефункциональные требования в системе в разрезе системного мышления?