1.6 Аттестация требований

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

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

Обзор требований. Требования системно анализируется рецензентами.

Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.

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

Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE - средства для проверки непротиворечивости моделей. Для автоматизированной проверки непротиворечивости необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.

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

Рассматривая приведенные выше методы аттестации требований, остановимся подробно на методе прототипирование, который будем использовать для построения программы-прототипа.

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

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

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

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

Интерфейс программы-прототипа был разработан в Microsoft Access 2003, этот программный продукт позволяет боле точно создать интерфейс и в случае необходимости его изменить.

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

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

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