Определение системы (System Definition Document).

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

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

Документ описывает системные требования вместе с информацией о бизнес-процессах, операционном окружении, организационных регламентов. Примером стандарта для создания и структурирования такого документа является IEEE 1362 «Concept of Operations Document».

 

5.2 Спецификация системных требований (System Requirements Specification).

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

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

  Системная инженерия самостоятельная и не менее объемная дисциплина, чем программная инженерия.

 

5.3 Спецификация программных требований (Software Requirements Specification - SRS).

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

 

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

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

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

Стандарт IEEE 830 является классическим примером стандарта на содержание структурирование и методы описания программных требований – «Recommended Practice for Software Requirements Specifications» («Рекомендуемая практика для спецификаций программных требований»).

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

При этом в спецификации требований просто включаются «картинки» пользовательского интерфейса с небольшими пояснениям.

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

· Терминологическая неопределенность

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

   Например, использование термина «требования». Под этим емким термином можно понимать, как требования к бизнес процессам, так и функциональные или нефункциональные требования к ПО вообще. 

· Отсутствие представления о классификации требований    

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

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

Например, проектные решения по использованию таблиц баз данных и несистематизированная и фрагментарная информация о бизнес-процессах организации. И все это «в одном флаконе».

· Фокусировка на деталях пользовательского интерфейса                  

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

· Излишнее акцентирование внимания на деталях реализации  

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

· Слабая формализация бизнес-процессов

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

 6. Проверка требований (Requirements Validation).

Определение требований напрямую связано с процедурами проверки и утверждения (аттестации - как это сформулировано в ГОСТ Р и ISO/ IEC 12207).

Вообще говоря, принято считать, что требования описаны не полностью, если для них не заданы правила V&V (verification & validation – проверка и аттестация), то есть, не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров - тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.

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

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

 

 

 

  6.1 Обзор требований (Requirements Review).

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

6.2 Прототипирование (Prototyping).

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

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

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

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

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

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

 

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

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