Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: kidman от 12 Февраля 2007, 12:53:08
-
Собственно, хотелось бы пообсуждать немного написание SRS на основе (по правилам) IEEE-STD-830-1998.
Собственно, столкнулся с проблемой...
Где его скачать? в оригинале, а не abstract... так сказать:)
П.С. Помогите плиз.
-
Держи стандарт (http://amd.streamload.com/anarchsyst/Hosted/Software_Requirements/IEEE-STD-830-1998.pdf)
Какие есть вопросы?
-
Держи
Спасибо!
Какие есть вопросы?
Вопросы чуть позже будут, как под (в) него буду под(в)гонять требования.
Спасибо!
-
А существует перевод?
Может имеет смысл взяться за эту работу?
-
А существует перевод?
Может имеет смысл взяться за эту работу?
Перевод не встречал. По сути это западный, более коммерциализированный вариант ГОСТ 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
-
Юрий, вы видели мой пост?
Правильно ли я понял ответ?
-
Сорри, не внимательно посмотрел ответ
Юрий, вы видели мой пост?
Правильно ли я понял ответ?
Не совсем. SRS по IEEE 830 ничего про ВИ не говорит ... да и я стараюсь придерживаться Вигерсовской классификации, что ВИ это в большей степени пользовательские требования. Другой вопрос, что они могут содержать функциональные требования (ФТ) в контексте их использования. Но это не есть ФТ в чистом виде.
Есть т.н. Modern SRS, где включаются UC ... но в классике -- фича, это некая укрупненная возможность ... которая детализируется потом в п. 3.2. ФТ ... как правило в виде иерархии.
-
Ок, спасибо за уточнения.
буду разбираться.
Тяжеловато без примеров. Нигде в инете не могу найти примеров:(
-
Ок, спасибо за уточнения.
буду разбираться.
Тяжеловато без примеров. Нигде в инете не могу найти примеров:(
Посмотри тут http://www.processimpact.com/process_assets/sample_requirements_documents.zip
-
Спасибо!!
Не чистый SRS по IEEE STD 830, но очень похоже, главное проверенное и правильное - полезная штука.
Спасибо!
-
Посмотри тут http://www.processimpact.com/process_assets/sample_requirements_documents.zip
Посмотрел и перевел. Перевод прилагается. Предлагаю развить пример до полного его употребления. Без реализации, только проектную часть во всех его деталях. Ну естественно выборочно.
-
Коллеги,
в результате обсуждения и просмотра обсуждаемых стандартов, выкладываю структуры документов - спецификаций требований к ПО:
* Стандарта IEEE-830-1998
* Шаблона спецификации требований к ПО Вигерса
* Технических Требований к ПО на основе ГОСТ 34.602-89
Два вложения - структуры в MS Word и MindManager
-
Добрый день.
Скажите пожалуйста, правильно ли я понял, что функциональные требования "Заказы питания" это требования которые вытекают из ВИ "Заказать блюдо (заказ блюд)"??? И если это так, то можно ли установить взаимосвязь между пунктами Сценария ВИ и функциональными требованиями???
(речь о документах "ТЗ" и "Варианты использования" из архива sample_requirements_documents_RUS.rar)
-
Снимаю шапку перед всеми!!! (хоть уже и столько лет прошло) :)
Мегаполезные доки!!!