Модели жизненного цикла программных средств. Требования к ПО, страница 5

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

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

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

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

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

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

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

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

Перечислим ряд ошибок, встречающихся при составлении технического задания и иных документов с требованиями:

1.  Описание возможных решений вместо требований

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

3.  Игнорирование аудитории для которой предназначено представление требований

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

Цикл работы с требованиями

В своде знаний по программной инженерии (SWEDOK) определяются следующие виды деятельности при работе с требованиями:

1.  Выделение требований- целенаправленная на выявление всех возможных источников требований и ограничений на работу системы и извлечение требований из этих источников.

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

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

4.  Валидация требований- решает задачу оценки принятности требований и их характеристик, на основе которых будут разработаны ПО, в силу непротиворечивости и полноты.

Конфигурационное управление

Файл- поименованная часть жестоко диска размеченная для хранения файла