Пример анализа и тестирования требований

Пример анализа и тестирования требований

Рассмотрим процесс создания чек-листа на основе итоговой версии требований.

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

Цели проекта:

• Исключение необходимости ручного подбора кодировок текстовых документов.
• Сокращение времени работы с текстовым документом на величину, необходимую для ручного подбора кодировки.

Метрики достижения целей:

• Полная автоматизация определения и преобразования кодировки текстового документа к заданной.
• Сокращение времени обработки текстового документа в среднем на 1–2 минуты на документ за счёт устранения необходимости ручного подбора кодировки( Из экспериментальных данных).

Риски:

• Проект у нас несколько специфичный — результатами работы программного средства будет пользоваться большое количество людей, но само программное средство при этом они использовать не будут (оно будет просто выполнять свою работу «само по себе» — запущенное на сервере с хранилищем документов). Потому под пользователем здесь мы будем понимать человека, настраивающего работу приложения на сервере. Из анализа хранилища документов было выяснено:
• Исходные форматы: plain text, HTML, MD.
• Исходные кодировки: CP1251, UTF8, CP866, KOI8R.
• Целевая кодировка: UTF8.

Выполним детализацию требований на более низких уровнях, т.к. появившиеся там вопросы позволят вернуться к бизнес-требованиям и улучшить их, если в этом возникнет необходимость.

Уровень пользовательских требований.

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

Разработаем диаграмму вариантов использования для данного приложения.

Для данного приложения были сформулированы требования:

1. Системные требования:

• СХ-1: Приложение является консольным.
• СХ-2: Для работы приложение использует интерпретатор PHP.
• СХ-3: Приложение является кроссплатформенным.

2. Пользовательские требования:

• Также см. диаграмму вариантов использования.
• ПТ-1: Запуск и остановка приложения.

ПТ-1.1: Запуск приложения производится из консоли командой «PHP

converter.php параметры».

ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C.

• ПТ-2: Конфигурирование приложения.

ПТ-2.1: Конфигурирование приложения сводится к указанию путей в файловой

системе.

ПТ-2.2: Целевой кодировкой является UTF8.

• ПТ-3: Просмотр журнала работы приложения.

ПТ-3.1: В процессе работы приложение должно выводить журнал

своей работы в консоль и лог-файл.

ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при

последующих — дописывается.

3. Бизнес-правила:

• БП-1: Источник и приёмник файлов

БП-1.1: Каталоги, являющиеся источником исходных и приёмником конечных

файлов не должны совпадать.

БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть

подкаталогом источника.

4. Атрибуты качества:

• АК-1: Производительность

АК-1.1: Приложение должно обеспечивать скорость обработки данных 5 МБ/сек.

• АК-2: Устойчивость к входным данным.

АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ

включительно.

АК-2.2: Если входной файл не является текстовым, приложение должно

произвести обработку.

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

Системные требования:

СХ-1: Приложение является консольным.

СХ-2: Для работы приложение использует интерпретатор PHP .

• Какая минимальная версия интерпретатора PHP поддерживается приложением? ( 5.5.x )
• Существует ли некая специфика настройки интерпретатора PHP для корректной работы приложения? ( Наверное, должен работать mbstring .)

• Настаиваете ли вы на реализации приложения именно на PHP? Если да, то почему . (Да, только PHP. У нас есть сотрудник, который его знает.)
• Должна ли в руководстве пользователя быть описана процедура установки и настройки интерпретатора PHP ? ( Нет.)

СХ-3: Приложение является кроссплатформенным .

• Какие ОС должны поддерживаться? ( Любая, где работает PHP .)
• В чём цель кроссплатформенности? ( Мы ещё не знаем, на чём будет работать сервер .)

Пользовательские требования:

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

ПТ-1: Запуск и остановка приложения.

ПТ-1.1: Запуск приложения производится из консоли командой « PHP ( возможно, здесь опечатка: должно быть php (в нижнем регистре)) ( Да, OK .) converter.php параметры ».

• Какие параметры передаются скрипту при запуске? ( Каталог с исходными файлами, каталог с конечными файлами. )

• Какова реакция скрипта на:

отсутствие параметров; (Пишет help.)

неверное количество параметров; (Пишет help и поясняет, что не так.)

неверные значения каждого из параметров. (Пишет help и поясняет, что не так.)

ПТ-1.2: Остановка приложения производится выполнением команды Ctrl+C (предлагаем дополнить это выражение фразой «в окне консоли, из которого было запущено приложение») ( Да, OK.).

ПТ-2: Конфигурирование приложения.

ПТ-2.1 : Конфигурирование приложения сводится к указанию путей в файловой системе.

• Путей к чему? (Каталог с исходными файлами, каталог с конечными файлами.)

ПТ-2.2 : Целевой кодировкой является UTF8.

• Предполагается ли указание иной целевой кодировки, или UTF8 используется в качестве целевой всегда? ( Только UTF8, других не надо .)

ПТ-3 : Просмотр журнала работы приложения.

ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в консоль и лог-файл.

• Каков формат журнала? ( Дата-время, что и с чем делали, что получилось)
• Различаются ли форматы журнала для консоли и лог-файла? (Нет.)
• Как определяется имя лог-файла? (Третий параметр при запуске. Если не указан — пусть будет converter.log рядом с php-скриптом.)

ПТ-3.2: При первом запуске приложения лог-файл создаётся, а при последующих — дописывается.

• Как приложение различает свой первый и последующие запуски ? ( Никак .)

• Какова реакция приложения на отсутствие лог-файла в случае, если это не первый запуск? (Создаёт. Тут идея в том, чтобы оно не затирало старый лог)

Бизнес-правила

БП-1 : Источник и приёмник файлов

БП-1.1: Каталоги, являющиеся источником исходных и приёмником конечных файлов, не должны совпадать.

• Какова реакция приложения в случае совпадения этих каталогов? ( Пишет help и поясняет, что не так .)

БП-1.2: Каталог, являющийся приёмником конечных файлов, не может быть подкаталогом источника

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

Атрибуты качества

АК-1: Производительность

АК-1.1 : Приложение должно обеспечивать скорость обработки данных 5 МБ/сек.

• При каких технических характеристиках системы? ( i7, 4GB RAM )

АК-2: Устойчивость к входным данным

АК-2.1: Приложение должно обрабатывать входные файлы размером до 50 МБ включительно.

• Какова реакция приложения на файлы, размер которых превышает 50 МБ? (Не трогает.)

АК-2.2: Если входной файл не является текстовым, приложение должно произвести обработку .

• Обработку чего должно произвести приложение? ( Этого файла. Не важно, что станет с файлом, лишь бы скрипт работал)

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

Системные требования

• СХ-1: Приложение является консольным.
• СХ-2: Приложение разрабатывается на языке программирования PHP (причина выбора языка PHP отражена в пункте О-1 раздела «Ограничения» , особенности и важные настройки интерпретатора PHP отражены в пункте ДС-1 раздела «Детальные спецификации»).
• СХ-3: Приложение является кроссплатформенным с учётом пункта О-4 раздела «Ограничения».

Пользовательские требования

• Также см. диаграмму вариантов использования.
• ПТ-1: Запуск и остановка приложения.
• ПТ-1.1 : Запуск приложения производится из консоли командой «php converter.php SOURCE_DIR DESTINATION_DIR [LOG_FILE_NAME]» ( описание параметров приведено в разделе ДС-2.1, реакция на ошибки при указании параметров приведена в разделах ДС-2.2, ДС2.3, ДС-2.4).

• ПТ-1.2 : Остановка приложения производится выполнением команды Ctrl+C в окне консоли, из которого было запущено приложение.
• ПТ-2: Конфигурирование приложения.
• ПТ-2.1: Конфигурирование приложения сводится к указанию параметров командной строки (см. ДС-2).
• ПТ-2.2: Целевой кодировкой преобразования текстов является кодировка UTF8 ( также см. О-5 ).
• ПТ-3: Просмотр журнала работы приложения.
• ПТ-3.1: В процессе работы приложение должно выводить журнал своей работы в консоль и лог-файл ( см. ДС-4 ), имя которого определяется правилами, указанными в ДС-2.1 .
• ПТ-3.2: Формат журнала работы и лог файла указан в ДС-4.1 , а реакция приложения на наличие или отсутствие лог-файла указана в ДС4.2 и ДС-4.3 соответственно.

Бизнес-правила

• БП-1 : Источник и приёмник файлов
• БП-1.1 : Каталоги, являющиеся источником исходных и приёмником конечных файлов, не должны совпадать ( см. также ДС-2.1 и ДС-3.2 ).
• БП-1.2 : Каталог, являющийся приёмником конечных файлов, не может находиться внутри каталога, являющегося источником исходных файлов или его подкаталогов ( см. также ДС-2.1 и ДС-3.2 ).

Атрибуты качества

• АК-1: Производительность
• АК-1.1: Приложение должно обеспечивать скорость обработки данных не менее 5 МБ/сек на аппаратном обеспечении, эквивалентном следующему: процессор i7, 4 ГБ оперативной памяти, средняя скорость чтения/записи на диск 30 МБ/сек. Также см. О-6.
• АК-2: Устойчивость к входным данным
• АК-2.1 : Требования относительно форматов обрабатываемых файлов изложены в ДС-5.1.
• АК-2.2: Требования относительно размеров обрабатываемых файлов изложены в ДС-5.2 .
• АК-2.3: Поведение приложения в ситуации обработки файлов с нарушениями формата определено в ДС-5.3.

• Ограничения
• О-1: Приложение разрабатывается на языке программирования PHP, использование которого обусловлено возможностью заказчика осуществлять поддержку приложения силами собственного IT-отдела.
• О-2 : Ограничения относительно версии и настроек интерпретатора PHP отражены в пункте ДС-1 раздела «Детальные спецификации».
• О-3 : Процедуры установки и настройки интерпретатора PHP выходят за рамки данного проекта и не описываются в документации.
• О-4 : Кроссплатформенные возможности приложения сводятся к способности работать под ОС семейства Windows и Linux, поддерживающих работу интерпретатора PHP версии, указанной в ДС-1.1 .
• О-5 : Целевая кодировка UTF8 является жёстко заданной, и её изменение в процессе эксплуатации приложения не предусмотрено.
• О-6 : Допускается невыполнение АК-1.1 в случае, если невозможность обеспечить заявленную производительность обусловлена объективными внешними причинами (например, техническими проблемами на сервере заказчика).

Детальные спецификации

• ДС-1: Интерпретатор PHP
• ДС-1.1: Минимальная версия — 5.5.
• ДС-1.2 : Для работы приложения должно быть установлено и включено расширение mbstring.
• ДС-2 : Параметры командной строки
• ДС-2.1 : При запуске приложения оно получает из командной строки три параметра: SOURCE_DIR — обязательный параметр, определяет путь к каталогу с файлами, которые необходимо обработать;

DESTINATION_DIR — обязательный параметр, определяет путь к каталогу,

в который необходимо поместить обработанные файлы (этот каталог не

может находиться внутри каталога SOURCE_DIR или в его подкаталогах ( см.

БП-1.1 и БП-1.2 ));

LOG_FILE_NAME — необязательный параметр, определяет полное имя лог-файла

(по умолчанию лог-файл с именем «converter.log» размещается по тому же пути,

по которому находится файл скрипта converter.php);

• ДС-2.2: При указании недостаточного количества параметров командной строки приложение должно завершить работу, выдав сообщение об использовании ( ДС-3.1 ).
• ДС-2.3 : При указании излишнего количества параметров командной строки приложение должно игнорировать все параметры командной строки, кроме указанных в пункте ДС-2.1 .
• ДС-2.4: При указании неверного значения любого из параметров командной строки приложение должно завершить работу, выдав сообщение об использовании ( ДС-3.1 ), а также сообщив имя неверно указанного параметра, его значение и суть ошибки ( см. ДС-3.2 ).
• ДС-3: Сообщения
• ДС-3.1 : Сообщение об использовании: «USAGE converter.php SOURCE_DIR DESTINATION_DIR LOG_FILE_NAME».
• ДС-3.2 : Сообщения об ошибках:

Directory not exists or inaccessible.

Destination dir may not reside within source dir tree.

Wrong file name or inaccessible path.

• ДС-4: Журнал работы
• ДС-4.1 : Формат журнала работы одинаков для отображения в консоли и записи в лог-файл: YYYY-MM-DD HH:II:SS имя_операции параметры_операции результат_операции.
• ДС-4.2: В случае если лог-файл отсутствует, должен быть создан новый пустой лог-файл.
• ДС-4.3 : В случае если лог-файл уже существует, должно происходить добавление новых записей в его конец.
• ДС-5: Форматы и размеры файлов
• ДС-5.1: Приложение должно обрабатывать текстовые файлы на русском и английском языках в следующих исходных кодировках: WIN1251, CP866, KOI8R. Обрабатываемые файлы могут быть представлены в следующих форматах, определяемых расширениями файлов: Plain Text (TXT); Hyper Text Markup Language Document (HTML); Mark Down Document (MD).

• ДС-5.2 : Приложение должно обрабатывать файлы размером до 50 МБ (включительно), игнорируя любой файл, размер которого превышает 50 МБ.
• ДС-5.3: Если файл с расширением из ДС-5.1 содержит внутри себя данные, не соответствующие формату файла, допускается повреждение таких данных.

Итак, получили набор требований, с которым уже вполне можно работать, чтобы разработчики смогли реализовать приложение, а тестировщики — протестировать его.