Документирование требований. Уровни детализации требований

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

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

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

Чтобы различить требования разных уровней детализации, используют термины пользовательские требования (user requirements) для обозначения обобщенных требований и системные требования (system requirements) для детализированного описания выполняемых программным изделием функций. Кроме требований этих двух уровней применяется еще более детализированное описание программного изделия, предназначенное для программистов - проектная системная спецификация (software design specification). Три перечисленных вида требований можно определить следующим образом.

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

Вместе с тем при описании требований на естественном языке могут возникнуть различные проблемы, связанные с неточностью и " размытостью" требований.

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

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

3. Объединение требований. Несколько различных требований к программному изделию могут описываться как единое пользовательское требование.

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

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

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

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

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

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

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

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