Стр: 55/301
Метрики достижения целей:
•
Полная автоматизация определения и преобразования кодировки текстового
документа к заданной.
•
Сокращение времени обработки текстового документа в среднем на 1–2 ми-
нуты на документ за счёт устранения необходимости ручного подбора коди-
ровки.
Риски:
•
Высокая техническая сложность безошибочного определения исходной ко-
дировки текстового документа.
Почему мы решили, что среднее время на подбор кодировки составляет 1–2
минуты? Мы провели наблюдение. Также мы помним ответы заказчика на вопросы
об исходных форматах документов, исходных и конечной кодировках (заказчик
честно сказал, что не знает ответа), а потому мы попросили его предоставить нам
доступ к хранилищу документов и выяснили:
•
Исходные форматы: plain text, HTML, MD.
•
Исходные кодировки: CP1251, UTF8, CP866, KOI8R.
•
Целевая кодировка: UTF8.
На данном этапе мы вполне можем решить, что стоит заняться детализацией
требований на более низких уровнях, т.к. появившиеся там вопросы позволят нам
вернуться к бизнес-требованиям и улучшить их, если в этом возникнет необходи-
мость.
Уровень пользовательских требований.
Пришло время заняться уровнем
пользовательских требований (см. главу «Уровни и типы требований»
{39}
)
. Проект у
нас несколько специфичный — результатами работы программного средства будет
пользоваться большое количество людей, но само программное средство при этом
они использовать не будут (оно будет просто выполнять свою работу «само по
себе» — запущенное на сервере с хранилищем документов). Потому под пользова-
телем здесь мы будем понимать человека, настраивающего работу приложения на
сервере.
Для начала мы создадим небольшую диаграмму вариантов использования,
представленную на рисунке 2.2.g (да, иногда её создают
Достарыңызбен бөлісу: |
