6. Процесс разработки требований. Свойства и категории требований.

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

Процесс разработки требований состоит из след. этапов:

1. Опрос заказчика для выявл-я требов-й, к-рые он предъявляет к ПО.

2. Подготовка документа, содержащего определения требований.

3. Подготовка спецификаций требований. Спецификация – документ, который описывает требования на специальном языке (для программистов).

4. Подготовка матрицы прослеживаемости требований. Матрица – таблица, которая ставит в соответствие каждому требованию - компоненты кода – компоненты модулей – компоненты тестов.

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

Опрос зак-ка производится в виде вопросов и ответов. Исп-ются слайды, макеты, чертежи, аналогичные проекты. Обмен инфы настолько важен, что затрачиваются значительные усилия и ср-ва на это. Присутствие специалиста по тестир-ю во время интервью позволяет узнать, как зак-к намерен исп-ть этот продукт, для того чтобы провести нужное реальное тест-ние. Для этого исп-ется: 1) метод JAD (join application development) совместная разработка приложений; 2) метод JAR (join application requirement) совместная разработка требований.

В рез-те проведения интервью с зак-ком надо извлечь соглашение относит-но приоритетов треб-й, т.е. каждое треб-е д.б. отнесено к одной из след. категорий:

• наиболее важное требование;

• требования, вып-ние к-рых желательно;

• требования, вып-ние к-рых желательно, но не обязательно.

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

1. Полнота. Набор треб-й счит-ся полным, если все его составные части представлены, и каждая часть выполнена в полном объеме. Треб-я не д. сод-ть выражений типа: и т.д., и прочее, подлежит дальнейшему определению, а также треб-я не д. ссылаться на несущ-вующие доки.

2. Однозначность. Треб-е д. содержать единственное толкование, а также д.б. удобочитаемым.

3. Непротиворечивость. Треб-я не д. противоречить друг другу.

4. Прослеживаемость. Каждое треб-е д.и. уник. идентификатор.

5. Осуществимость. Каждое треб-е д. ставить реально выполнимые задачи, как с функциональной точки зрения, так и с точки зрения времени и затрат ср-в на разработку.

6. Контролепригодность. Треб-я д.б.измеряемыми в приемлемых усл.

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

• Каждое требование должно иметь уникальный ID;

• Требование д.б. представлены с точки зрения пользовательской системы и не затрагивать внутренние свойства системы;

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

Категории требований.

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

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

3. Данные – описывают входные и выходные данные системы. Какой при этом используется формат, какие данные н. сохранить, какой объем данных поступит из системы, с какой точностью должны выполняться вычисления.

4. Производительность – проблемы масштабирования и синхронизации (например, ск-ко пользователей одновременно д. обслуживать система).

5. Польз-ли и чел-ий фактор – описаны треб-я к тем, кто будет раб-ть с прогой, их квалиф-я, опыт, ур-нь удобства и простоты испыт-я.(ск-ко отдел. действий треб-ся для вып-я опер-ии в системе).

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

7. Безопасность – как осуществляется доступ к системе, к ее данным, где они сохраняются и как часто дублируются.

8. Документация – в каком виде д.б. документация (печатном или электронном) и для кого она предназначена.

9. Устранение неисправностей – как система д. реагировать на возникновение сбоя (аварийный сигнал, сообщений) время простоя до зависания.

10. Сопровождение и план поставки версий – как и кем производится поставка новых версий.

Спецификация требований.

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

Спецификация – документ, который описывает требования на специальном языке (понятном для программистов).

7. Хронологический порядок тестирования.

Хронология тестирования:

1. Создаются и тестируются отдельные элементы проги – 1-ая часть модульного тестирования (м-д белого ящика)

2. Эти эл-ты объединяются в одно целое, как подсистемы и тестируются (м-д черного ящика)

3. подсистемы объединяются в систему и тестируются (интеграционное тестирование)

4. Полученная сис-ма помещается в реальное окружение пользователя и подвергаются тестированию (функциональное тестирование).

5. Эти системные тесты сохраняются для повторного выполнения в случае внесения изменений (регресионное тестирование)

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

Этапы модульного тестирования.

1. Планирование модульного тестирования;

2. Разработка тестов;

3. Формирование отладочных заданий;

4. Процесс тестирования;

5. Обработка результатов тестирования;