Кое-что о SRS — Спецификация требований ПО (выдержки из IEEE Std 830-1998)
Основные понятия
— договор: обязанный по закону документ, составленный на основе соглашения между заказчиком и поставщиком. Он включает технические и организационные требования, стоимость и график выполнения работ в отношении продукта. Договор может также содержать неофициальную, но полезную информацию, такую как обязательства или ожидания сторон-участниц.
— заказчик: лицо или лица, которые оплачивают продукт и обычно (но необязательно) устанавливают требования. В контексте настоящего документа заказчик и поставщик могут быть членами одной и той же организации.
— поставщик: лицо или лица, которые производят продукт для заказчика. В контексте настоящего документа заказчик и поставщик могут быть членами одной и той же организации.
— пользователь: лицо или лица, которые работают или взаимодействуют напрямую с продуктом. Пользователь(и) и заказчик(и) часто являются одними и теми же лицами.
Определение
SRS является спецификацией для определенного программного продукта, программы или набора программ, и которая выполняет определенные функции в определенной среде.
SRS должна определить, какие функции должны выполняться на основе каких данных для выполнения каких результатов в каком месте для кого. SRS должна концентрироваться на услугах, которые должны выполняться. Обычно SRS НЕ должна определять такие элементы проекта, как:
— разбиение ПО на модули;
— распределение модулей на функции;
— описание информационного потока или контроль между модулями;
— выбор структур данных.
Основными вопросами, которые должен рассматривать SRS, являются следующие
1. Функциональные возможности. Что должно делать ПО?
2. Внешние интерфейсы. Как ПО взаимодействует с людьми, с системными аппаратными средствами, с другими аппаратными средствами и другим ПО?
3. Производительность. Какова скорость, доступность, время реакции, время восстановления различных функций ПО и т. д.?
4. Атрибуты. Какова мобильность, корректность, сопровождаемость, безопасность, другие вопросы?
5. Проектные ограничения, наложенные на внедрение. Существуют ли на самом деле необходимые стандарты, язык внедрения, стратегии для целостности базы данных, ресурсные ограничения, операционная среда(ы) и т. д.?
Составитель SRS должен избегать внесения в SRS либо конструктивных, либо проектных требований.
Свойства SRS
1. корректной;
2. однозначной;
3. полной;
4. непротиворечивой;
5. ранжированной по важности и/или стабильности; (интересное свойство допускающее разбиение на обязательные и желательные требования, тем самым закладывая возможность для модернизации)
6. верифицируемой;
7. изменяемой;
8. трассируемой.
Верифицируемость
SRS считается верифицируемой только в том случае, если каждое установленное в ней требование является верифицируемым. Требование считается верифицируемым только в том случае, если существует некоторый рентабельный процесс, посредством которого человек или машина могут проверить, удовлетворяет ли программный продукт требованию. Вообще никакое неоднозначное требование не является верифицируемым.
Неверифицируемые требования включают такие утверждения как «работает хорошо», «хороший интерфейс с пользователем» и «должен обычно происходить». Данные требования не могут быть проверены из-за невозможности определения терминов «хороший», «хорошо» или «обычно». Утверждение «программа никогда не должна вводить бесконечный цикл» является неверифицируемым, т.к. тестирование качества теоретически невозможно.
Примером верифицируемого утверждения является:
Выходные данные программы должны производиться в пределах 20 с события х 60% времени, а также в пределах 30 с события х 100% времени.
Данное утверждение можно проверить, т.к. оно использует конкретные термины и измеряемые количественные характеристики.
Если метод невозможно разработать для определения, удовлетворяет ли ПО определенному требованию, то это требование следует удалить или пересмотреть.
Трассируемость
SRS считается трассируемой только в том случае, если происхождение каждого требования является понятным и оно облегчает составление ссылок на каждое требование в документации к будущей разработке или улучшению. Рекомендуются следующие два вида трассируемости:
— Обратная трассируемость (т.е. по отношению к предыдущим этапам разработки). Она зависит от каждого требования, которое дает четкую ссылку на источник в более ранних документах.
— Прямая трассируемость (т.е. по отношению ко всем документам, которые порождает SRS). Она зависит от каждого требования в SRS, которое имеет однозначное имя или номер ссылки.
Прямая трассируемость SRS является особенно важной в том случае, когда программный продукт вводится в стадию эксплуатации и сопровождения. Т.к. изменяются документы к коду и проекту, является важным возможность установления полного набора требований, которые могут затрагиваться данными изменениями.
Роли
Процесс разработки ПО должен начинаться с соглашения между поставщиком и заказчиком, по которому должно выполняться полное ПО. Данное соглашение в форме SRS должно подготавливаться совместно. Это важно, т.к. обычно ни заказчик, ни поставщик не имеет достаточной квалификации для собственного составления пригодной SRS.
— Заказчики обычно не понимают процесс разработки и проектирования ПО достаточно хорошо, чтобы составить SRS, которая могла бы использоваться.
— Поставщики обычно не понимают проблему и область стремлений заказчика достаточно хорошо, чтобы определить требования для удовлетворения системе.
Следовательно, заказчик и поставщик должны работать вместе, чтобы создать SRS, которая была бы хорошо написана и полностью понимаема.
Существует определенная ситуация, когда система и ее ПО определяются одновременно. В таком случае функциональные возможности, интерфейсы, производительность, а также другие атрибуты и ограничения ПО скорее определяются не предварительно, а совместно и являются объектом переговоров и изменений.
Содержание
1. Введение
1.1. Назначение
1.2. Область применения
1.3. Определения, сокращения и аббревиатура
1.4. Ссылки
1.5. Обзор
2. Общее описание
2.1. Перспектива продукта
2.2. Функции продукта
2.3. Характеристики пользователя
2.4. Ограничения
2.5. Предположения и зависимости
3. Специфичные требования (См. пункты 5.3.1-5.3.8 Стандарта для объяснения возможных специфичных требований. См. также Приложение A Стандарта для нескольких различных способов организации настоящего раздела.) — данный раздел является основным, так как предельно детализирует требования
Приложения
Индекс
P.S. еще информация по теме http://habrahabr.ru/post/52681/
