Перевод с англ.: (C)
Dale, 27.04.2011 — 29.04.2011.
IEEE STD 830-1998
(Ревизия IEEE STD 830-1993)
Спонсор: Комитет по стандартам в области программной инженерии Компьютерного сообщества IEEE.
Одобрено 25 июня 1998 года Советом по стандартам IEEE-SA.
Реферат: Описаны содержание и характеристики качественной спецификации требований к программному обеспечению (software requirements specification, SRS), приведены несколько примеров плана SRS. Эти рекомендации ориентированы на составление спецификаций требований к разрабатываемому программному обеспечению, но также могут помочь при выборе коммерческих и разработанных самостоятельно программных продуктов. Также приведены указания по согласованию со стандартом IEEE/EIA 12207.1-1997.
Ключевые слова: контракт, потребитель, прототипирование, спецификация требований к программному обеспечению, поставщик, спецификация системных требований.
(Данное введение не является составной частью Стандарта)
Данные рекомендации описывают рекомендованный подход к разработке спецификаций требований к программному обеспечению. Они основываются на модели, в которой результатом процесса разработки спецификации требований к программному обеспечению является непротиворечивый и полный документ. Они призваны помочь:
- Потребителям программного обеспечения – точно описать, что они желают получить;
- Поставщикам программного обеспечения – в точности понять, что хочет потребитель;
- Специалистам – выполнить следующие задачи:
- Разработать план стандартной спецификации требований к программному обеспечению (SRS) для нужд вашей конкретной организации;
- Определить формат и содержание своих собственных спецификаций требований к программному обеспечению;
- Разработать собственные дополнительные инструменты поддержки, такие, как чек-листы качества SRS или справочники разработчиков SRS.
Для потребителей, поставщиков и прочих специалистов качественная SRS должна обеспечить несколько преимуществ, в частности:
- Установить основу для соглашения между потребителями и поставщиками о том, что должен делать программный продукт. Полное описание выполняемых программным обеспечением функций, заданное в SRS, поможет потенциальным пользователям определить, удовлетворяет ли программное обеспечение их потребности, либо каким образом его следует модифицировать для удовлетворения их потребностей.
- Снизить трудоемкость разработки. Подготовка SRS заставляет различные заинтересованные группы в организации-потребителе тщательно рассмотреть все требования до начала разработки и уменьшить последующие перепроектирование, перекодирование и перетестирование. Внимательный пересмотр требований в SRS может выявить упущения, недоразумения и несогласованности на ранних стадиях цикла разработки, когда эти проблемы легче исправить.
- Обеспечить основу для оценки стоимости и сроков. Описание разрабатываемого продукта, приведенное в SRS, является реалистичной основой для оценки затрат на проектирование и может быть использовано для обоснования цены.
- Обеспечить основу для валидации и верификации. Руководствуясь хорошей SRS, организации могут гораздо продуктивнее разработать собственные планы валидации и верификации. Как часть контракта на разработку SRS обеспечивает эталон, соответствие которому может быть оценено.
- Облегчить передачу. SRS облегчает передачу программного обеспечения новым пользователям или на новые машины. Таким образом, потребители обнаруживают, что упрощается передача программного обеспечения в другие подразделения их организации, а поставщики обнаруживают, что облегчается его передача новым потребителям.
- Служить основой для усовершенствования. Поскольку в SRS обсуждается сам продукт, а не проект его разработки, SRS служит основой для последующего усовершенствования завершенного продукта. Может потребоваться изменение SRS, но она все равно является основой для дальнейшей оценки продукта.
Читатели данного документа могут обратиться к !!!Приложению Б за указаниями по использованию данных рекомендаций в соответствии с требованиями стандарта IEEE/EIA 12207.1-1997.
(Опущен весьма объемистый список лиц, которым документ обязан своим появлением на свет).
Данные рекомендации описывают рекомендованный подход к составлению спецификаций требований к программному обеспечению. Они делятся на 5 разделов.
- Раздел 1 поясняет область применимости рекомендаций.
- Раздел 2 перечисляет ссылки на другие стандарты.
- В разделе 3 приведены определения основных используемых терминов.
- Раздел 4 предоставляет дополнительную информацию по написанию хорошей SRS.
- В разделе 5 обсуждаются все основные части SRS.
Данные рекомендации содержат также два приложения; в одном представлены альтернативные форматы шаблонов, в другом – указания по соответствию со стандартом IEEE/EIA 12207.1-1997.
Данный документ представляет собой рекомендации по написанию спецификаций требований к программному обеспечению. Он описывает содержание и характеристики качественной спецификации требований к программному обеспечению (SRS) и представляет несколько примеров плана SRS.
Данные рекомендации ориентированы на специфицирование требований к разрабатываемому программному обеспечению, но могут также оказаться полезны при выборе самостоятельно разработанных и коммерческих продуктов. Однако их применение к уже разработанному программному обеспечению может отрицательно повлиять на продуктивность.
Если программное обеспечение встроено в некоторую большую систему, например, медицинское оборудование, то могут возникнут проблемы, лежащие вне пределов применимости данных рекомендаций.
Данные рекомендации описывают процесс создания продукта и содержание продукта. Продуктом является SRS. Рекомендации могут быть непосредственно использованы для создания SRS или как модель для более специфического стандарта.
Данная рекомендация не предлагает никаких конкретных методов или инструментов для подготовки SRS.
(Опущен перечень ссылок на другие стандарты).
В общем определения терминов, используемых в данных рекомендациях, соответствуют определениям, приведенным в IEEE Std 610.12-1990. Ниже приведены определения ключевых терминов, используемых в данных рекомендациях.
3.1. Контракт: Юридический документ, согласованный между потребителем и поставщиком. Он включает технические и организационные требования, цены и сроки поставки продукта. Контракт может также включать неформальную, но полезную информацию, например, обязательства или ожидания заинтересованных сторон.
3.2. Потребитель: Персона (персоны), которая оплачивает продукт и обычно (но не обязательно) определяет требования к нему. В контексте этих рекомендаций потребитель и поставщик могут принадлежать к одной и той же организации.
3.3. Поставщик: Персона (персоны), которая производит продукт для потребителя. В контексте этих рекомендаций потребитель и поставщик могут принадлежать к одной и той же организации.
3.4. Пользователь: Персона (персоны), которая непосредственно управляет или взаимодействует с продуктом. Пользователь (-ли) и потребитель (-ли) зачастую не являются одной и той же персоной.
Этот раздел представляет информацию, которую следует иметь в виду при написании SRS. Она включает следующее:
- Природа SRS;
- Окружение SRS;
- Характеристики качественной SRS;
- Совместная подготовка SRS;
- Эволюция SRS;
- Прототипирование;
- Встраивание разработки в SRS;
- Встраивание проектных требований в SRS.
SRS – это спецификация отдельного программного продукта, программы или набора программ, которые выполняют некоторые действия в некоторой среде. SRS может быть написана одним или несколькими представителями поставщика, одним или несколькими представителями потребителя, или совместно представителями обеих сторон.
Подраздел 4.4 рекомендует участие в этом процессе обеих сторон.
Основные вопросы, которые должны решить авторы SRS, следующие:
- Функциональность. Что должно по замыслу делать программное обеспечение?
- Внешние интерфейсы. Как программное обеспечение взаимодействует с людьми, системным оборудованием, другим оборудованием и другими программами?
- Производительность. Каковы скорость, доступность, время ответа, время восстановления различных программных функций и т.д.?
- Атрибуты. Каковы переносимость, корректность, пригодность к поддержке, безопасность и т.д.?
- Проектные ограничения, налагаемые на реализацию. Есть ли требования к действующим стандартам, языкам реализации, политикам поддержания целостности баз данных, ограничениям на ресурсы, операционной среде и т.д.?
Авторам SRS следует избегать включения требований к проектированию и разработке в SRS.
Рекомендуемое содержание SRS приведено в
разделе 5.
Важно сознавать роль, которую SRS играет в общем плане проекта и которая определена в IEEE Std 610.12-1990. Программное обеспечение может содержать полностью всю функциональность проекта либо быть частью более крупной системы. В последнем случае обычно бывает SRS, устанавливающая интерфейсы между системой и ее программной частью и определяющая внешние требования к производительности и функциональности программной части. Разумеется, впоследствии SRS должна согласовываться с этими системными требованиями и детализироваться на их основе.
IEEE STD 1074-1997 описывает этапы жизненного цикла программного обеспечения и допустимые входные данные для каждого этапа. Другие стандарты, например, перечисленные в
разделе 2, ссылаются на другие части жизненного цикла программного обеспечения и таким образом могут дополнять требования к программному обеспечению.
Поскольку SRS играет особую роль в процессе разработки программного обеспечения, авторы SRS должны проявлять осторожность и не выходить за границы этой роли. Это значит, что SRS
- должна корректно определять все требования к программному обеспечению. Требование к программному обеспечению может существовать благодаря природе решаемой задачи либо благодаря специфической особенности проекта.
- не должна описывать никаких деталей разработки и реализации. Их следует описывать на стадии разработки проекта.
- не должна накладывать дополнительные ограничения на программное обеспечение. Они должным образом задаются в других документах, например, плане обеспечения качества программного обеспечения.
Таким образом, правильно написанная SRS ограничивает диапазон допустимых проектных решений, но не задает никакого конкретного решения.
SRS должна быть:
- корректной;
- непротиворечивой;
- полной;
- целостной;
- упорядоченной по важности и/или стабильности;
- верифицируемой;
- модифицируемой;
- трассируемой.
SRS является корректной в том и только том случае, если программное обеспечение действительно должно удовлетворять каждому установленному требованию.
Не существует инструментов или процедур, которые обеспечивали бы корректность. Следует сравнивать SRS со всеми подходящими вышестоящими спецификациями, например, спецификациями требований к системе, с другой программной документацией и другими подходящими стандартами, с целью обеспечить их согласованность. Кроме того, потребитель или пользователь могут определить, корректно ли SRS отражает их действительные потребности. Трассируемость делает эту процедуру более простой и менее подверженной ошибкам (см.
4.3.8).
SRS является непротиворечивой в том и только том случае, если каждое установленное требование имеет только одну интерпретацию. Как минимум это означает, что каждая характеристика конечного продукта должна описываться одним и тем же уникальным термином. В случаях, когда термин, используемый в данном контексте, может иметь несколько значений, следует включить термин в глоссарий, где его смысл уточняется.
SRS – важная часть процесса управления требованиями в жизненном цикле программного обеспечения, и она используется при разработке, реализации, отслеживании проекта, верификации проекта, а также при обучении, как описано в IEEE STD 1074-1977. SRS должна быть непротиворечива как с точки зрения того, кто ее создает, так и с точки зрения того, кто ее использует. Однако эти группы зачастую имеют различные точки зрения и поэтому не стремятся описывать требования к программному обеспечению одинаковым образом. Представление, которое улучшает спецификацию требований с точки зрения разработчика, может быть непродуктивным, если оно ухудшает понимание со стороны пользователя, и наоборот.
Подразделы с
4.3.2.1 по
4.3.2.3 рекомендуют, как избегать неоднозначности.
Требования часто пишутся на естественном языке (например, английском). Естественные языки неоднозначны по своей природе. SRS на естественном языке должна быть пересмотрена независимой стороной с целью выявления неоднозначного использования языка, которое должно быть исправлено.
Один из способов избежать неоднозначности, свойственной естественным языкам, – это написать SRS на особом языке спецификации требований. Его языковые процессоры автоматически находят многие лексические, синтаксические и семантические ошибки.
Одним из недостатков при использовании подобных языков является продолжительность времени, необходимого для их изучения. Кроме того, многие пользователи без технической подготовки находят их непонятными. Напротив, эти языки более выразительны для некоторых типов требований и некоторых типов систем. Таким образом, они могут оказывать тонкое влияние на требования.
В целом методы разработки требований, языки и инструменты их поддержки делятся на три основные категории – объект, процесс и поведение. Объектно-ориентированные подходы организуют требования в терминах объектов реального мира, их атрибутов и сервисов, выполняемых этими объектами. Процесс-ориентированные подходы организуют требования в иерархии функций, которые взаимодействуют посредством потоков данных. Поведенческие подходы описывают внешнее поведение системы в терминах некоторой абстрактной нотации (такой, как исчисление предикатов), математических функций или конечных автоматов.
Степень, в которой подобные инструменты и методы могут быть полезны при подготовке SRS, зависят от размера и сложности программы. В данном документе не предпринимаются попытки описать или рекомендовать какой-либо конкретный инструмент.
При использовании любого из этих подходов лучше всего придерживаться описания на естественном языке. В этом случае потребители, незнакомые с нотациями, все же будут способны понимать SRS.
SRS является полной в том и только том случае, если она включает в себя следующие элементы:
- Все значимые требования, имеющие отношение к функциональности, производительности, проектным ограничениям, атрибутам или внешним интерфейсам. В частности, следует принимать во внимание все внешние требования, налагаемые системной спецификацией.
- Определение всех ответов программного обеспечения на все возможные классы входных данных во всех возможных классах ситуаций. Отметим, что важно задавать ответы как на допустимые, так и на недопустимые входные значения.
- Все метки и ссылки на все рисунки, таблицы и диаграммы в SRS, а также определения всех терминов и единиц измерения.
Любая SRS, в которой используется фраза «следует определить» (“to be determined”, TBD), не является полной. Впрочем, иногда TBD необходимы и должны сопровождаться:
- описанием условий, вызвавших TBD (например, почему ответ неизвестен), чтобы ситуация могла быть разрешена;
- описанием того, что должно быть сделано для удаления TBD, кто ответственный за это удаление и к какому сроку оно должно быть удалено.
Понятие «целостность» относится к внутренней целостности. Если SRS не согласуется с каким-либо из документов высшего уровня, например, спецификацией требований к системе, она не является корректной (см.
4.3.1).
SRS является внутренне целостной в том и только том случае, если никакое подмножество описанных в ней отдельных требований не конфликтуют друг с другом. Ниже приведены три наиболее вероятных типа конфликтов в SRS:
- Специфические характеристики объектов реального мира могут конфликтовать. Например:
- Формат вывода отчета может быть описан в одном требовании как таблица, а в другом – как текст.
- Одно требование может устанавливать, что все лампочки должны быть зелеными, а другое – синими.
- Может быть логический или временной конфликт между двумя заданными действиями. Например:
- Одно требование может задавать, что программа должна складывать два введенных числа, а другое – что она должна перемножать их.
- Одно требование может устанавливать, что «А» должно всегда следовать за «Б», в то время как другое требует, чтобы «А» и «Б» происходили одновременно.
- Два или более требований могут описывать одни и те же объекты реального мира, но использовать при этом разные термины. Например, запрос программой пользовательского ввода может называться «подсказкой» в одном требовании и «приглашением» в другом. Использование стандартной терминологии и определений способствует повышению целостности.
SRS является упорядоченной по важности и/или стабильности, если каждое требование в ней имеет идентификатор, указывающий либо важность, либо стабильность данного требования.
Как правило, не все требования, относящиеся к программному продукту, являются одинаково важными. Одни требования могут быть принципиально важными, особенно для жизненно-важных приложений, тогда как другие могут быть просто желательными.
Каждое требование в SRS должно быть идентифицировано с целью сделать эти различия отчетливыми и явными. Идентификация требований таким образом помогает:
- потребителям – более тщательно рассмотреть каждое требование, что зачастую проясняет их неявные предположения.
- разработчикам – принимать правильные проектные решения и соответственно распределять усилия, затрачиваемые на различные части программного продукта.
Один из методов идентификации требований использует оценку стабильности. Стабильность может быть выражена как число ожидаемых изменений требования, оцениваемое на основе опыта или знания предстоящих событий, которые повлияют на организацию, функции или персонал, использующий программную систему.
Другой способ ранжировать требования – разделить классы требований на обязательные, желательные и необязательные.
- Обязательные. Подразумевается, что программное обеспечение не будет приемлемо, если требование не выполняется надлежащим образом.
- Желательные. Подразумевается, что данные требования улучшат программный продукт, но их отсутствие не делает программный продукт неприемлемым.
- Необязательные. Подразумевается класс функций, которые могут оказаться полезными, а могут и не оказаться. Это дает поставщику возможность предложить что-то, выходящее за пределы SRS.
SRS является верифицируемой в том и только том случае, если каждое требование является верифицируемым. Требование является верифицируемым в том и только том случае, если существует некий конечный достаточно эффективный процесс, согласно которому человек либо машина может проверить, удовлетворяет ли программный продукт данному требованию. В общем случае никакое неоднозначное требование не является верифицируемым.
Неверифицируемые требования включают такие обороты, как «работает хорошо», «хороший человеко-машинный интерфейс» или «обычно должно происходить». Эти требования невозможно верифицировать, поскольку невозможно точно установить смысл терминов «хорошо», «хороши» или «обычно». Утверждение «программа никогда не должна входить в бесконечный цикл» не является верифицируемой, поскольку его тестирование невозможно даже теоретически.
Пример верифицируемого утверждения:
Вывод программы должен производиться в пределах 20 секунд в 60% случаев, и должен производиться в пределах 30 секунд в 100% случаев.
Данное утверждение может быть верифицировано, поскольку в нем используются конкретные термины и измеряемые величины.
Если невозможно придумать способ определения, удовлетворяет ли программное обеспечение данному требованию, это требование должно быть удалено или пересмотрено.
SRS является модифицируемой в том и только том случае, если ее структура и стиль таковы, что любые изменения требования могут быть сделаны легко, полно и целостно без изменений этих структуры и стиля. Модифицируемость обычно требует от SRS:
- иметь связную и легкую в использовании организацию с оглавлением, индексом и явными перекрестными ссылками;
- не быть избыточным (например, одно и то же требование не должно появляться более чем в одном месте в SRS);
- представлять каждое требование отдельно, не смешивая с другими требованиями.
Сама по себе избыточность ошибкой не является, но легко может привести к ошибке. Порой избыточность помогает сделать SRS более читаемой, однако может возникнуть проблема при обновлении избыточного документа. Например, требование может быть изменено лишь в одном месте среди тех, где оно появляется. В этом случае SRS перестает быть целостной. Если избыточность действительно необходима, следует включать в SRS явные перекрестные ссылки, чтобы сделать ее модифицируемой.
SRS является трассируемой, если источник каждого требования ясен и если она в дальнейшем позволит ссылаться на каждое требование в документации разработки. Рекомендуются следующие два типа трассируемости:
- Обратная трассируемость (т.е. к предыдущим этапам разработки). Она зависит от наличия в каждом требовании явной ссылки на его источник в предшествующей документации.
- Прямая трассируемость (т.е. ко всем документам, порожденным SRS). Она зависит от наличия в SRS уникального имени или ссылочного номера для каждого требования.
Прямая трассируемость SRS особенно важна, когда программный продукт переходит в фазу использования и поддержки. Поскольку код и проектная документация модифицируемы, важно иметь возможность уточнить весь набор требований, которые могут быть затронуты этими изменениями.
Процесс разработки программного обеспечения должен начинаться соглашением между поставщиком и потребителем о том, что именно должно делать готовое программное обеспечение. Это соглашение, оформленное в виде SRS, должно быть подготовлено совместно. Это важно, поскольку обычно ни потребитель, ни поставщик по отдельности не имеют достаточной квалификации для самостоятельного написания хорошей SRS.
- Потребители обычно не имеют представления о разработке программного обеспечения в объеме, достаточном для написания полезной SRS.
- Поставщики обычно не имеют понимания задач потребителя и предметной области в степени, достаточной для задания требований к системе удовлетворительного качества.
Таким образом, потребитель и поставщик должны работать вместе для создания хорошо написанной и совершенно понятной SRS.
Особая ситуация возникает, когда одновременно определяется система и ее программное обеспечение. В этом случае функциональность, интерфейсы, производительность и прочие атрибуты и ограничения программного обеспечения не предопределены, а скорее определяются совместно и являются предметом соглашений и изменений. Это делает достижение характеристик, перечисленных в
4.3, более трудным, но не менее важным. В частности, SRS, которая не согласуется с требованиями родительской системы, является некорректной.
В данных рекомендациях не обсуждаются особый стиль, использование языка или технология хорошего написания. Однако весьма важно, чтобы SRS была написана хорошо. В качестве руководства можно использовать общие руководства по написанию технических текстов.
SRS может потребовать развития по мере продвижения процесса разработки программного продукта. Может оказаться невозможным задать некоторые детали во время начала проекта (например, может быть невозможно определить все экранные формы для интерактивных программ в фазе сбора требований). Дополнительные изменения могут возникнуть по мере обнаружения недостатков, дефектов и неточностей в SRS.
При этом необходимо учитывать два важных аспекта:
- Требования должны быть заданы настолько полно и тщательно, насколько возможно в данный момент, даже если очевидно, что впоследствии неизбежен их пересмотр. Следует отметить факт их неполноты.
- Следует начать формальный процесс для идентификации, управления, отслеживания и учета запланированных изменений. Одобренные изменения должны вноситься в SRS таким образом, чтобы:
- обеспечивать точное и полное протоколирование изменений;
- позволять пересмотр текущих и замененных частей SRS.
Прототипирование часто используется на проектном этапе работы с требованиями. Существует множество инструментов для быстрого и легкого изготовления прототипов, демонстрирующих некоторые характеристики системы. См. также ASTM E1340-96.
Прототипы полезны по следующим причинам:
- Потребитель может предпочесть посмотреть и оценить прототип, нежели читать и оценивать SRS. Поэтому прототип обеспечивает быструю обратную связь.
- Прототип демонстрирует неожиданные аспекты поведения системы. Таким образом, он не только дает ответы, но и задает новые вопросы. Это помогает более полно проанализировать SRS.
- SRS, основанная на прототипе, имеет тенденцию меньше подвергаться изменениям во время разработки, тем самым сокращая время разработки.
Прототип следует использовать как способ извлечения требований. Некоторые характеристики, наподобие форм отчетов, могут быть непосредственно извлечены из прототипа. Другие требования могут возникнуть в ходе экспериментирования с прототипом.
Требование задает видимую извне функцию или атрибут системы. Разработка описывает некоторую составную часть системы и/или ее интерфейсы с остальными частями. Авторы SRS должны отчетливо различать идентификацию требуемых проектных ограничений и разработку проекта. Заметим, что каждое требование в SRS ограничивает выбор проектных решений. Тем не менее, из этого не следует, что каждое требование есть разработка.
SRS должна задавать, какие функции необходимо выполнить над какими данными, какой получить результат, где и для кого. SRS должна фокусироваться на выполняемых сервисах. Обычно SRS не должна задавать конкретных проектных решений, например:
- разбиение программного обеспечения на модули;
- назначение функций модулям;
- описание потоков информации или управления между модулями;
- выбор структур данных.
В особых случаях некоторые требования могут существенно ограничить разработку. Например, требования к секретности или безопасности могут непосредственно отразиться на разработке в виде необходимости
- хранить некоторые функции в отдельных модулях;
- позволять только ограниченные коммуникации между некоторыми областями программы;
- проверять целостность данных для критических переменных.
Примерами допустимых ограничений разработки являются физические требования, требования к производительности, стандарты на разработку программного обеспечения и стандарты по обеспечению качества.
Таким образом, требования следует устанавливать с чисто внешней точки зрения. Используя модели для иллюстрации требований, помните, что модель отражает лишь внешнее поведение и не задает никаких конкретных проектных решений.
SRS должна быть направлена на сам программный продукт, а не на процесс его изготовления.
Проектные требования представляют соглашения между потребителем и поставщиком по поводу деталей контракта, относящихся к производству программного обеспечения, поэтому их не следует включать в SRS. Обычно в их число входят:
- Стоимость;
- График поставки;
- Процедуры отчетности;
- Методики разработки программного обеспечения;
- Обеспечение качества;
- Критерии валидации и верификации;
- Процедуры приемки.
Проектные требования задаются в других документах, обычно в плане разработки программного обеспечения, плане обеспечения качества или в общих положениях проекта.
Продолжение.