Главная страница | Контакты | Случайная страница Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Виды и свойства требований

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

Ясность, недвусмысленность — однозначность понимания требований заказчиком и разработчиками.

Полнота и непротиворечивость.

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

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

Тестируемость и проверяемость — необходимо, чтобы существовали способы оттестировать и проверить данное требование. необходимы процедуры проверки –выполнение тестов, проведение инспекций, проведение формальной верификации части требований и пр.

Модифицируемость. Определяет процедуры внесения изменений в требования.

Вопрос Варианты формализации требований

Требования как таковые – это некоторая абстракция. В реальной практике они всегда существуют в виде какого-то представления – документа, модели, списка и т.д. Требования важны как таковые, потому что оседают в виде понимания разработчиками, нужд заказчика и будущих пользователей создаваемой системы. Но так как в программном проекте много различных аспектов, видов деятельности и фаз разработки, то это понимание может принимать очень разные представления и формализовано оно будет по -разному. Итак, формализация требований в проекте может быть очень разной – это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Рассмотрим варианты.

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

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

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

Формальная модель требований для верификации, модельно-ориентированного тестирования и т.д.

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