Одной из главных проблем сбора требований является проблема изменения требований. Требования появляются в процессе общения между группой заказчиков и аналитиками системы в виде интервью, обсуждений, которые не приносят желаемого результата. Это объясняется тем, что составляющих элементов требований последовательно изменяются, благодаря чему их содержание и форма постепенно становятся более точными и полными, т.е. соответствуют действительности.
Инструменты трассировки поддерживают развитие и обработку требований с сохранением их описания и внутренних связей между ними. Трассировка помогает проверять особенности системы на спецификациях требований, выявлять источники разнообразных ошибок и управлять изменениями требований. Если требования разрабатывались в объектной ориентации, то объектами трассировки являются классы и суперклассы и поддерживаемые отношения между ними.
Некоторые методы трассировки базируются на формальных спецификациях отношений (фреймы, соглашения сотрудничества и др.), другие ограничиваются описаниями действий, ситуаций, контекста и возможных решений.
Трассировку можно описать исходя из следующего:
1) требования изменяются во время функционирования системы;
2) возникновение требований и их расположение зависит от деталей практической ситуации и контекста их возникновения (требования можно изменить, изменяя эти детали);
3) трассировка требований должна поддерживаться и изменятся на протяжении всего ЖЦ программного продукта (т.к. изменяются сами требования, необходимо проводить изменение и промежуточных результатов, полученных при анализе, спецификации, кодировке и т.д.);
4) для удобства трассировки использовать иерархическую структуру связей между требованиями, основу которой составляет информация об атрибутах требований.
Чтобы принять решение о возможных модификациях, необходимо иметь достаточно информации о частях и связях между ними. Более того, различные аспекты требований могут быть по-разному представлены и изменены их контексты путем персонального вмешательства аналитиков или заказчика.
Человеческий фактор. Любой процесс постановки требований напрямую связан с умением людей контактировать друг с другом, кооперироваться или эффективно распределять разноплановые производственные функции между собой. Необходимо уметь достигнуть соглашения в спорных вопросах, касающихся дизайна или технических решений. Организационные функции не должны выходить за рамки понимания проблемы. Важно чтобы лица, работающие над проектом на разных уровнях, имели возможность эффективно общаться друг с другом. Технологии проекта должны обращать внимание на динамику людских отношений в коллективе. Они должны способствовать эффективному достижению согласия и управления разногласиями, давать возможность снижать сложность отношений в группе сотрудников, работающих над проектом, особенно в повседневной работе при создании высококачественного продукта.
ВОПРОСЫ ДЛЯ РАССМОТРЕНИЯ.
1. Как называется этап ЖЦ разработки ПО, на котором фиксируется контракт между заказчиком и исполнителем разработки?
2. Назовите действующих лиц процесса формирования требований.
3. Назовите источники сведений о требованиях.
4. Какова последовательность шагов по использованию действующей системы в новой разработке?
5. Назовите категории классификации требований.
6. Цели и составляющие концептуального моделирования проблемы.
7. Что определяет онтология концептуального моделирования проблемы?
8. Объясните суть отношений, с помощью которых строятся понятия: обобщение, декомпозиция, абстракция, ассоциация.
9. Приведите задачи трассировки требований.
10. Расскажите о принципах взаимоотношений между заказчиком и разработчиком требований к системе.
Рекомендуемая литература по теме
1. Леонов И.В. Введение в методологию разработки программного обеспечения при помощи Rational Rose. Требования к системе и способы использования// igorvleonov@esc.ru
2. Вигерс К.И. Разработка требований к ПО. Москва, 2004.– Русская редакция Microsoft.–575c.