3. Требования. Место в жц разработки ис

Получить заказ можно двумя способами:

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

2. Аукцион, торги, конкурсные мероприятия. Здесь теребования очень важно сформулировать. Если мы заказчик, то требования нужно формулировать более мягко. Если мы исполнители, то мы описываем план выполнения, надо все уточнять(калькулятор).

Формулирование требований – это этап, который определяет кто что и в каком объеме будет делать.

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

1. Пользовательские требования. ПТ это описание на естественном языке функций, выполняемых системой и ограничений, накладываемых на нее. Самая понятная информация – это графическая – самая простая.

2. Системные требования. Представляют из себя детализированное описание системных функций и ограничений.

3. Проектная системная спецификация. Обобщенное описание структуры программной системы, которое будет являться основой для более детального ее проектирования.

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

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

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

Для проектной системной спецификации пользователи – это все что выше, кроме конечных пользователей.

На этапе формирования заявки формируются только первые 2 требования, исполнитель уже предложит спецификацию.

4. Функциональные требования

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

ФТ. Сервис – услуга, функция. Если ФТ оформлены как пользовательские, то они, как правило, описывают систему в общем виде. ФТ оформленные как системные описывают систему максимально подробно, включая входные и выходные данные, исключительные ситуации и т.д. сами требования могут быть представлены различными способами, но основной из них – текстовая форма. Главное, чтобы эти требования не были противоречивыми. И на практике достаточно тяжело разработать комплексную непротиворечивую систему – нет единой точки зрения на весь процесс.

5. Нефункциональные требования

НеФТ описывают характеристики системы и ее окружения, а не поведение системы. также здесь могут быть указаны ограничения, накладываемые на действия или функции, которые включают ограничения: временные, ограничения на процесс разработки, на стандарты и т.д.

НеФТ. Многие НеФТ относятся к системе в целом, а не к отдельным ее средствам. Это означает, что они более значимы и критичны, чем отдельные функциональные требования. Ошибка в соблюдении ФТ может привести к снижению качества системы, ошибка при не удовлетворении НеФТ приводит к полностью неработоспособной системе.

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

Классификация НеФТ:

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

   1. требования к эксплуатации

   2. требования к эффективности

1.2.1 требования к производительности

1.2.2 требования к памяти

1.3 требования к надежности

3. требования к переносимости

1. организационные требования

   1. выходные требования

   2. требования на реализацию

   3. требования на стандарты

2. внешние требования

   1. требования на взаимодейсвтие

   2. этические требования

   3. юридические требования

      1. требования о сохранении конфиденциальности

      2. требования по технике безопасности