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

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

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

Данный документ, часто называемый как “спецификация пользовательских требований” (user requirements specification) или “концепция” (concept <of operations>), описывает системные требования. Содержание документа определяет высокоуровневые требования, часто – стратегические цели, для достижения которых создается программная система. Принципиальным моментом является то, что такой документ описывает требования к системе с точки зрения области применения - “домена”. Соответственно, изложение требований в нем ведется в терминах прикладной области. Документ описывает системные требования вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов. Примером стандарта для создания и структурирования такого документа является IEEE 1362 “Concept of Operations Document”.

В сложных проектах принято разделять спецификацию системных требований (system requirements) и спецификацию программных требований (software requirements). При таком подходе программные требования порождаются системными требованиями и детализируют требования к компонентам и подсистемам программного обеспечения. Документ описывает программную систему в контексте системной инженерии (system engineering), идеи которой кратко описаны в Главе 12 SWEBOK “Связанные дисциплины программной инженерии”. Строго говоря, спецификация системных требований описывает деятельность системных инженеров и выходит за рамки обсуждения SWEBOK. Стандарт IEEE 1233 является одним из признанных руководств по разработке системных требований. И, как уже отмечалось ранее, не стоит забывать о том, что понятие система, в общем случае, охватывает программное обеспечение, аппаратную часть и людей. Системная инженерия (см. материалы INCOSE – www.incose.org ), в свою очередь, самостоятельная и не менее объемная дисциплина чем программная инженерия. SWEBOK рассматривает системную инженерию как важную связанную дисциплину. Ну а системные требования – один из элементов реального связывания различной инженерной деятельности - программной и системной.

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

Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать. Документ может включать процедуры проверки получаемого программного обеспечения на соответствие предъявляемым ему требованиям (вплоть до содержания планов тестирования), характеристики, определяющие качество и методы его оценки, вопросы безопасности и многое другое. Часто программные требования описываются на обычном языке. В то же время, существуют полуформальные и формальные методы и подходы, используемые для спецификации программных требований. В любом случае, задача состоит в том, чтобы программные требования были ясны, связи между ними прозрачны, а содержание данной спецификации не допускало разночтений и интерпретаций, способных привести к созданию программного продукта, не отвечающего потребностям заинтересованных лиц. Стандарт IEEE 830 является классическим примером стандарта на содержание структурирование и методы описания программных требований – “Recommended Practice for Software Requirements Specifications”.

Необходим отметить, что в документацию на требования не следует вносить элементы дизайна системы (скажем, логическую модель базы данных). А вот сценарии использования Use Case часто включают в спецификацию требований наравне с трассировкой (traces) к соответствующим моделям в форме диаграмм, например, к UML Use Case, UML Activity, BPMN и т.п. . Говоря о написании спецификаций требований, то есть одно серьезное заблуждение, которое делают обычно неопытные аналитики – это фактическая подмена требований как таковых, моделями графического пользовательского интерфейса, т.е. когда в документы-спецификации требований просто включаются «картинки» пользовательского интерфейса с небольшими пояснениям. Это отнюдь не означает, что с заинтересованными лицами и в частности с пользователями, не следует вообще обсуждать дизайн GUI, часто это имеет смысл делать, но для этого существует, например, прототипирование. Мне довелось изучить многие документы требований в разных организациях и практически все они имели одни и те же проблемы:

  • Терминологическая неопределенность. Часто используются термины, которые обладают многозначностью, и такие термины не определены в глоссариях, чтобы можно было четко понять, что конкретно автор имеет в виду в данном случае (это не всегда бывает понятно из контекста). Как пример можно привести собственно использование (и, что немаловажно, понимания!) термина «требования». Под этим ёмким термином можно понимать как требования к бизнес процессам, так и функциональные или нефункциональные требования к ПО вообще. Интересно, что на уровне многих стандартов (к сожалению, в основном, англоязычных) прописано использование тех или иных глаголов, форм и структурирование предложений, описывающих требования – например использование глаголов (will, shall, should, may, can – перечислены в порядке “убывания директивности”). Действительно, “программный модуль X отсылает уведомление на e-mail адрес пользователя...” несет, мягко говоря, иную смысловую нагрузку, чем “отсылается сообщение”.
  • Отсутствие представления о классификации требований. Подмена одних категорий требований – другими и смешение требований (например, такое часто случается с функциональными требованиями, бизнес-требованиями и бизнес-правилами). Как результат – создаваемые документы тяжело читать и извлекать полезную для разработки ПО информацию. Зачастую в одном абзаце, можно встретить перемешанные как описания необходимой функциональности и тут же элементы предполагаемого пользовательского интерфейса, который должен воплотить разработчик. Или проектные решения, например, использование таблиц баз данных или полей. И помимо этого, содержится несистематизированная и фрагментарная информация о бизнес-процессах организации. Все это скрывает истинные требования к разрабатываемому ПО, что в свою очередь затрудняет как разработку, так и согласование требований. Корректная и однозначная интерпретация требований и анализ влияний становятся практически неосуществимыми, что напрямую сказывается на адекватности удовлетворения потребностей заказчика/пользователей.
  • Фокусировка на деталях пользовательского интерфейса. В документах встречается акцентирование не на необходимой функциональности, а на деталях пользовательского интерфейса.
  • Излишнее акцентирование внимания на деталях реализации. Попытка отразить в документе с требованиями к создаваемому ПО не ЧТО должна делать система, а то КАК она это будет делать. Это одна из ключевых проблем. Во многом, поэтому, часто выделяют внутренние технические требования к системе, которые не проходят аттестации со стороны пользователей и разрабатываются не аналитиками, а архитектором и ведущими разработчиками уже на этапе проектирования – software design (см. следующую область знаний SWEBOK).
  • Слабая формализация бизнес-процессов. В документах перемешивается описание бизнеса и требования к ПО, что приводит сложностям в понимании сути и общему пониманию как должна быть спроектирована система.