Собственно, хотелось бы пообсуждать немного написание SRS на основе (по правилам) IEEE-STD-830-1998.

Собственно, столкнулся с проблемой...
Где его скачать? в оригинале, а не abstract... так сказать:)

П.С. Помогите плиз.

Держи стандарт

Какие есть вопросы?

Держи

Спасибо!

Какие есть вопросы?

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

Спасибо!

А существует перевод?
Может имеет смысл взяться за эту работу?

А существует перевод?
Может имеет смысл взяться за эту работу?

Перевод не встречал. По сути это западный, более коммерциализированный вариант ГОСТ 34.602 (вкупе с IEEE Std 1233-1998 - Guide for Developing System Requirements Specifications), основанный на структурно-функциональном подходе к пониманию систем.

Мне кажутся более полезными шаблоны и руководства по созданию Концепции, Описаний прецедентов и Нефункциональных требований из RUP.

Но вообще идея хорошая. Хотя опять же вопросы прав.

Э ... вот если честно встречал я перевод стандарта IEEE 830, мне как-то прислали. Я правда так и не удосужился посмотреть его ...

Предлагаю выложить его в файловый архив

Предлагаю выложить его в файловый архив

Добавил: http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=82

Интересует взаимосвязь пунктов 2.2 Product functions и 3.2 Functions:

Должен ли пункт 3.2 раскрывать пункт 2.2, давая более детальные указания для разработчика?
Или там может быть несоответствие в структуре, названиях в функциях?
Тоесть 3.2 перечисляет все функциональные требования и дает исчерпывающие инструкции.
А 2.2 просто перечисляет основные функции и фичи.


П.С. Буду рад увидеть самплы SRS

Один из способов -- в п.2.2. должны быть фичи, а в п 3.2 фичи делализируются конкретными требованиями (и группируются по фичам). Так легче контролировать scope, гогда он "обложен" фичами.

Модератор: Пожалуйста, пишите нормальными словами, или поясняйте значения сленга...

Один из способов -- в п.2.2. должны быть фичи, а в п 3.2 фичи делализируются конкретными требованиями (и группируются по фичам). Так легче контролировать scope, гогда он "облюжен" фичами.

Не по теме. Это на каком языке написано? :-))

Модератор: ответ по теме ...

Один из способов -- в п.2.2. должны быть фичи, а в п 3.2 фичи делализируются конкретными требованиями (и группируются по фичам). Так легче контролировать scope, гогда он "облюжен" фичами.

Модератор: Пожалуйста, пишите нормальными словами, или поясняйте значения сленга...

Это значит что я могу указать функциональность в виде списка фич, разбить их тематически например. в Пункте 2.2
А в пункте 3.2 Предоставить ВИ для каждой фичи и расписать ВИ. + дополнить их при помощи Activity diagrams + расписать все неперекрытое ВИ и Activity diagrams?
Правильно ли я понимаю?

Спасибо за ответ.

Один из способов -- в п.2.2. должны быть фичи, а в п 3.2 фичи делализируются конкретными требованиями (и группируются по фичам). Так легче контролировать scope, гогда он "облюжен" фичами.

Модератор: Пожалуйста, пишите нормальными словами, или поясняйте значения сленга...

Немного поясню:
Фича или feature или характиристика - это основные функции или хар-ки, которые система должна делать.
Scope или масштаб - это описание границ проекта.

Т.е. переведя на русский, получается:
Хар-ки Системы описываются в п.2.2., а в п 3.2 они детализируются требованиями (и группируются по хар-кам Системы)
Если известны основные хар-ки Системы, то легче контролировать масштаб проекта и не вылезать особенно в сторону за рамки проекта, когда фантазия клиента сильно разыграется.

Саша, спасибо за коментарий. Никак не могу привыкнуть, что требуется пояснять что такое feature (фича), и что это не сленг а вполне себе термин.
Модератору -- см. на тему фич тут http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf

Юрий, вы видели мой пост?
Правильно ли я понял ответ?