Трассирование требований

Одной из главных проблем сбора требований является проблема изменения требований. Требования появляются в процессе общения между группой заказчиков и аналитиками системы в виде интервью, обсуждений, которые не приносят желаемого результата. Это объясняется тем, что составляющих элементов требований последовательно изменяются, благодаря чему их содержание и форма постепенно становятся более точными и полными, т.е. соответствуют действительности [6].

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

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

Трассировку можно описать исходя из следующего:

1) требования изменяются во время функционирования системы;

2) возникновение требований и их расположение зависит от деталей практической ситуации и контекста их возникновения (требования можно изменить, изменяя эти детали);

3) трассировка требований должна поддерживаться и изменятся на протяжении всего ЖЦ программного продукта (т.к. изменяются сами требования, необходимо проводить изменение и промежуточных результатов, полученных при анализе, спецификации, кодировке и т.д.);

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

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

Механизмы трассировки должны учитывать следующее:

1) вместо простых связей вводить более сложные отношения (например, транзитивное отношение для выделения цепочек связей) или вводить специфические отношения;

2) использовать сложные и гибкие пути трассировки;

3) поддержать базы данных объектов трассировки и отношений между ними.

Желательно наличие механизмов поддержки возможностей объектно-ориентированного программирования, операций над классами, а также механизмов унификации функций и отношений (1:1, 1:N, N:M), уничтожение и изменение связей, установка стандартных связей.

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

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

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

Наиболее привычной и результативной моделью отношений между заказчиком и проектировщиком является модель типа «учитель – ученик». На практике заказчик наблюдает за работой проектировщика системы. Когда заказчик его не беспокоит, проектировщик обращает внимание на примеры и сам отвечает себе на возникающие вопросы. В порядке исключения, заказчик может остановить свою работу, обдумать поставленный вопрос для пояснения и удовлетворения проектировщика.

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

Контрольные вопросы и задания

1. Как называется этап ЖЦ разработки ПО, на котором фиксируется контракт между заказчиком и исполнителем разработки?

2. Назовите действующих лиц процесса формирования требований.

3. Назовите источники сведений о требованиях.

4. Какова последовательность шагов по использованию действующей системы в новой разработке?

5. Назовите категории классификации требований.

6. Цели и составляющие концептуального моделирования проблемы.

7. Что определяет онтология концептуального моделирования проблемы?

8. Объясните суть отношений, с помощью которых строятся понятия: обобщение, декомпозиция, абстракция, ассоциация.

10. Назовите элементы объектно-ориентированного моделирования программных систем.

11. В чем состоит принцип сокрытия информации?

12. Определите концепция модели сценариев для сбора требований.

13. Дайте пояснения для нотации диаграммы сценариев и базовых отношений в них.

14. Назовите основные типы объекты модели.

15. Приведите задачи трассировки требований.

16. Расскажите о принципах взаимоотношений между заказчиком и разработчиком требований к системе.

Литература к теме 3

1. Леонов И.В. Введение в методологию разработки программного обеспечения при помощи Rational Rose. Требования к системе и способы использования// [email protected]

2. Вигерс К.И. Разработка требований к ПО. Москва, 2004.– Русская редакция Microsoft.–575c.

3. Pamela Zave, Michael Jackson, «Four Dark Corners of Requirements Engineering», ACM Transactions on Software Engineering, January 1997, №1.

4. Jacobson I., Griss M., Jonsson P. Software Reuse. - N.-Y. - Addиson-Wesley, 1997. - 497p.

5. http:/www.rational.com.uml.html

6. Francisco A. C. Pinheiro, Joseph A. Goguen, «An Object - Oriented tool for Tracing Requirements», «Software», Mach 1996, № 3.

Тема 4