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

После того как требования были собраны, мы переходим к следующей стадии — к Анализу требований. На этом этапе необходимо выявить и устранить конфликты между требованиями и различными заинтересованными лицами, нормативными документами, законодательной базой, бизнес-процессами компании и действующими на предприятии системами. Устанавливаются общие границы проекта. Проводится классификация требований по уровням — 1) Бизнес-требования — описывают цель, задачи, назначение проекта создания ИС 2) Функциональные требования — предписывают требуемые варианты поведения ИС, определяющие способы рещения поставленных задач 3) Пользовательские требования — это задачи, решение которых является одной из первопричин создания конкретной ИС.

Несколько другой вариант классификации по ряду различных параметров приводится в главе Requirements Analysis по SWEBOK [9]:

Функциональные и нефункциональные требования Внутренние (с другими требованиями) или внешние зависимости Требования к процессу или продукту Приоритет требований Содержание требований в отношении конкретных подсистем создаваемого программного обеспечения Изменяемость/стабильность требований [9].

Другой популярной классификацией требований к программным системам по уровням является классификация FURPS+, разработал которую в 1992 году сотрудник компании Hewlett-Packard Роберт Грэйди. Её название представляет собой аббревиатуру по первым буквам слов Functionaliy, Usability, Reliability, Perfomance и Supportability. Под «+» обозначаются ограничения — Constrains.

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

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

Лицензирование — инструмент контроля над покупкой, установкой и использованием лицензий.

Почта — служба по обмену сообщениями.

Онлайн-помощь — возможность оказания помощи пользователям в режиме реального времени.

Печать — возможность вывода документов на печать.

Отчетность — инструменты по возможности создания отчетов.

Безопасность — инструменты по защите и ограничению доступа к отдельным видам информационных ресурсов.

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

Блок Usability, или Удобство использования, содержит следующие относящиеся к нему виды требований: Интерфейс пользователя должен быть логичен и эстетичен; Должна существовать защита от человеческого фактора; Справочная информация должна содержаться в системе;

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

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

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

Блок «+», Constrains, или Ограничения, все те требования, которые ограничивают разработчика в выборе средств. Могут касаться любого аспекта — реализации программного кода, используемых мощностей, форматам входных и выходных данных, ограничений на физические параметры, начиная с формы и размера аппаратного обеспечения и заканчивая необходимой температурной средой.

Проблема заинтересованных лиц.

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

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