Потребности, требования, ограничения

Знание о существовании различных видов систем в их относительном положении от целевой системы в системной холархии позволяет более строго ввести всем знакомые понятия потребностей, требований и ограничений. Но перед этим нам нужно ввести понятие «чёрного ящика» (black box): это какая-то система, которую мы представляем без знаний о внутреннем её устройстве – мы только можем наблюдать внешнюю границу этой системы (границу её экстента), т.е. наблюдаем только занимаемое место в пространстве-времени, её свойства, поведение (и тем самым функцию), но ничего не знаем о внутреннем устройстве.

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

Конечно, терминология может меняться. Например, требования для предприятия вряд ли будут называть именно «требованиями», чаще их называют стратегия (strategy) – какое-то ожидаемое поведение или свойство предприятия как целого, как чёрного ящика (например, стратегия – это на какой рынок будет выходить предприятие, как оно будет себя там вести). Часто слово «системные» опускают и говорят о просто «требованиях».

Очень часто те люди, которые формулируют требования или стратегию, хотят указать не только внешние свойства системы, описать не только границы системы и её поведение как чёрного ящика, но и указать какие-то детали внутреннего устройства системы: определить (define) части системы (подсистемы), указать на процесс взаимодействия подсистем. В этом случае о системе говорят как о «прозрачном ящике», в нём можно считать известными какие-то подсистемы, свойства и поведение этих подсистем. Если в какой-нибудь «спецификации» или «требованиях технического задания» среди требований встречаются описания прозрачного ящика (упоминания подсистем), то их называют ограничениями (constraints). Эти ограничения нужно понимать как ограничения конструкторской свободы команды, которая должна разработать и изготовить систему.

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

Если рассмотреть использующую систему как чёрный ящик, то её определение будет потребностями стейкхолдеров (stakeholder needs, нужды стейкхолдеров), хотя иногда и говорят о «требованиях стейкхолдеров» (stakeholder requirements). Не путайте требования стейкхолдеров с системными требованиями: это определения разных вложенных друг в друга систем! Так что люди во избежание путаницы предпочитают про требования стейкхолдеров говорить потребности/нужды/needs.

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