1.4. Требования к проекту

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

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

Система должна предоставлять пользователю доступ к балансу его банковского счета.

Вообще говоря, следующее выражение (N) не является требованием для при­ложения.

Балансы счетов клиентов будут храниться в таблице под названием «балан­сы» в базе данных Access.

Второе выражение касается того, как должно быть построено приложение, а не того, что это приложение должно делать.

Требование на одном уровне часто переходит в одно или несколько конкретных требований на следующем, более подробном уровне. Чтобы понять это, представь­те себе, что ваше требование для будущего дома — «видеть горы на 180 градусов вокруг». Это требование может перейти в утверждение, что «терраса справа должна иметь размеры 20 х 50 футов». Это более конкретное требование на более детальном уровне. Аналогично, утверждение (N) действительно может стать тре­бованием на последующих уровнях процесса разработки.

Более того, встречаются исключения из правила, запрещающего специфици­ровать в требованиях, как должно работать приложение. Например, у заказчика могут быть особые причины потребовать, чтобы балансы счетов хранились в ба­зе данных Access с конкретным именем, и тогда утверждение(N) действительно становится требованием.

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

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

1) Интерфейс пользователя для ОУ должен позволять оператору:

— задавать значения основных атрибутов ОУ (геометрические размеры и физические свойства);

— задавать текущее значение температуры окружающей среды T_ос;

— переключать автоматический и ручной режимы управления;

— изменять в ручном режиме управления значения величин U(τ), I(τ), υ(τ), с шагом неболее 0.01 от максимального значения;

— индицировать в режиме реального времени текущую температуру пластинки.

2) Интерфейс пользователя для регулятора должен позволять оператору:

— задавать значения настроек регулятора;

— задавать значение заданной температуры T_зад(τ)с точностью ±0.2 °С.

3) ПО модели ОУ и регулятора должно быть выполнено в виде отдельных программных модулей (EXE-файлов) запускаемых на разных машинах. Связь модулей между собой должна обеспечиваться использованием сетевых технологий.

4) В ПО модели АСУ ТМП должна быть реализована модель технологического процесса изображенного на рис. 1 и модель АСУ представленная на рис. 2.

5) ПО модели АСУ ТМП должно работать в режиме реального времени.

В соответствии с индивидуальными заданиями требования могут дополняться.