Выявление и анализ требований

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

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

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

1. "система должна использовать СУБД Oracle для хранения данных",

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

Возможно, причиной появления первой формулировки является тот факт, что СУБД Oracle уже используется организацией для хранения данных в действующих системах, которые должны быть интегрированы с проектируемой. В этом случае задачу лучше сформулировать так: "должно быть организовано надежное и удобное для интеграции с другими системами хранение данных".

Вторая формулировка излишне конкретна и предлагает решение проблемы вместо ее формулировки. Лучше сформулировать соответствующую задачу следующим образом: "необходимо предотвращать попадание некорректных данных в хранилище".

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

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

· Все данные о сделках и клиентах будут сохраняться в базе данных.

· Статус выполнения заказа клиент сможет узнать через Интернет.

· Система будет поддерживать до 10000 одновременно работающих пользователей.

· Расписание проведения ремонтных работ будет строиться автоматически.

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

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

Рисунок 17 - Проблемы, потребности, функции и требования

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

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

Правила работы с требованиями к ПО определяются следующими двумя стандартами IEEE:

1. СтандартIEEE 830-1998 Recommended Practice for Software Requirements Specifications (Рекомендуемые методы спецификации требований к ПО), описывающий структуру документов для фиксации требований к ПО и определяющий характеристики правильно составленного набора требований.

2. Стандарт IEEE 1233-2002 Guide for Developing System Requirements Specifications (Руководство по разработке спецификаций требований к системам), описывающий правила построения требований для программно-аппаратных систем в целом.

Указанными стандартами определяются следующие свойства набора требований:

· Однократное упоминание отдельных требований.

· Отсутствие пересечений между требованиями.

· Явное указание связей между требованиями.

· Полнота.

· Непротиворечивость.

· Определение ограничений, области действия и контекста для каждого требования.

· Модифицируемость.

· Конфигурируемость, удобство поддержки.

· Подходящий для определения системы уровень абстракции.

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

· Абстрактность — формулировка, независимая от возможных реализаций.

· Недвусмысленность.

· Прослеживаемость.

· Проверяемость.

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

· Уникальный идентификатор.

· Приоритет, важность реализации с точки зрения пользователей.

· Критичность для построения и успешности системы с точки зрения аналитиков.

· Осуществимость с точки зрения готовности пользователей к новой функции, имеющихся технологий и стоимости реализации.

· Риски высокой стоимости, последствий использования для окружающей среды и пользователей, конфликтов со стандартами и законодательством.

· Источник (т.е. кто предложил это требование).

· Тип требования:

Требования на входные данные.
Требования на выходные данные.
Надежность (reliability, например, среднее время работы между отказами).
Работоспособность (availability, например, необходимое отношение времени функционирования к полному времени работы).
Удобство сопровождения (maintainability, например, удобство замены компонента).
Производительность (performance, например, среднее время ожидания ответа).
Доступность (accessibility, например, разные способы доступа для новичков и опытных пользователей).
Ограничения окружающей среды (например, максимальный уровень задымленности, при котором гарантируется работоспособность).
Эргономичность (ergonomic, например, использование набора цветов, понижающих утомляемость глаз).
Безопасность (safety, например, допустимые уровни электромагнитного излучения различных частот).
Защищенность (security, например, ограничения доступа для разных пользователей).
Требования к оборудованию.
Транспортируемость (transportability, например, ограничения веса).
Удобство обучения (например, включение обучающих материалов).
Документированность (например, наличие встроенной документации).
Внешние интерфейсы (например, поддержка форматов документов).
Тестируемость (например, поддержка удаленной диагностики).
Следование корпоративным и законодательным нормам (например, законам об охране труда).
Совместимость с известными системами.
Следование стандартам и технологическим нормам.
Конвертация данных (например, из старой версии системы).
Возможности роста (например, увеличение числа пользователей).
Удобство развертывания (например, время развертывания).

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

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

2. Слишком детальные спецификации, описывающие требования к слишком мелким элементам системы или описывающие требования, в точности соответствующие характеристикам определенных систем.

3. Слишком сильные ограничения, не вытекающие из реальных потребностей.

4. Нечеткие требования, которые могут быть непроверяемыми и субъективными ("минимизировать уровень погрешности", "удобный для пользователей интерфейс"), или сформулированы в виде, открытом для пополнения неопределенными элементами (с указанием "и т.д." или "включая, но не ограничиваясь следующим...").

5. Несформулированные предположения о режимах работы, свойствах окружения, о готовности других систем или принятии законов и стандартов, находящихся в стадии разработки.

Вопросы разработки требований к программным системам будут детально рассматриваться в отдельной дисциплине, предусмотренной учебным планом направления подготовки бакалавров 231000.62 – "Программная инженерия" в 6-м и 7-м семестрах.