Как Вы описываете требования к ПО?(Прочитано 43138 раз)
В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?

Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.
Плюсы такого подхода:
1. Учитываются все требования
2. Наиболее понятны и детализированы для программиста
3. Наиболее понятны для заказчика, можно дать почитать

Хотелось услышать другие мнения и минусы моего подхода, если они есть.
« Последнее редактирование: 05 Марта 2007, 00:51:40 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Как Вы описываете требования к ПО? Ответ #1 : 05 Марта 2007, 14:08:59
Самым "сложным" случаем с т.з. процесса документирования требований будет такой, когда есть заказчик который трубует документацию требований в определенном формате (например по ГОСТ 34.602) а у компании-разработчика свои стаднарты (например те же UC и иже с ним). В этом случае нужно формировать документацию требований по ГОСТ из тех требований, которые создаются самими аналитиками компании-разработчика. Тут вариантов 2 либо делать требования в классическом иерархическом виде, что маппится 1 в 1 на ТЗ по ГОСТ, либо впихывать в ТЗ по ГОСТ (или в разные наборы документов по ГОСТ) юзкейсы и иже с ним. При всем при этом крайне желательно пользоваться каким-либо инструментарием и поддерживать синхронизацию изменений в обоих артефактах. Идеальный случай, когда требования ведуться в неком репозитории и документация создается автоматически.
Что касается использования юзкейсов -- то формально говоря, это пользовательские требования (по тому же Вигерсу). С другой стороны, в них содержится и собственно информация о том, какая функциональность должна быть в системе. Но формально говоря, (с т.з. формального определения из глоссария IEEE что есть требование) это <> функциональным требования. Т.е. UC это контейнер для функц. требований по большому счету. Да, можно описать достаточно подробно юзкейсы с дополнительными слотами, где учесть и некоторые нефункциональные требования, которые "привязаны" к данному UC. И для целого ряда систем этого будет достаточно для проектирования системы. Но следует помнить и тот факт, что не всегда удается описать юзкейсами всю нужную ФУНКЦИОАЛЬНОСТЬ системы. И это одна из причин почему их относят таки к ПОЛЬЗОВАТЕЛЬСКИМ требованиям. И даже если взглянуть на RUP, то там в Supplementary Spec. есть отдельные слоты для описания ФУНКЦИОНАЛЬНЫХ требований, которые не были охвачены юзкейсамы.
« Последнее редактирование: 05 Марта 2007, 14:12:40 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Как Вы описываете требования к ПО? Ответ #2 : 05 Марта 2007, 18:15:22
В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?

Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.
Саша, "мы добавляем к сценариям ВИ нефункциональные требования и бизнес-правила" - это не ответ на вопрос КАК мы описываем требования и с КАКОЙ детализациией :)

Мы стараемся выделять фунциональные требования, нефункциональные и ограничения.

Стремимся к такой модели по функциональным требованиям - 1-5 бизнес-задач, из них 10-20 бизнес-требований, из них 50-100 пользовательских требований. Проработка каждого следующего уровня выполняется при наличии ресурсов/критичности системы. Бизнес-задачи формулируются в виде утверждений, привязанных к целям системы. Бизнес-требования - как условия выполнимости этих бизнес-задач. Пользовательские требования, нефункциональные и ограничения начинают формулироваться примерно одновременно. Первоначально пользовательские требования формулируются в виде утверждений-целей пользователя. Затем по возможности описываются одним абзацем текста в виде краткого описания основного сценария прецедента. По возможности детализируются пошагово и снабжаются описаниями исключений.

Требования к структурам данных формулируются в виде диаграмм предметной области. Требования к интерфейсу - в виде макетов. Прочие нефункциональные требования - в виде утверждений + приложений со спецификациями форматов, программных интерфейсов, ссылок на стандарты.



Re: Как Вы описываете требования к ПО? Ответ #3 : 05 Марта 2007, 18:36:11
Денис, согласен, описал как-то скомкано, но было поздно, а хотелось дать пищу для размышления.

И так, требования именно к ПО мы описываем в виде единого документа (шаблон взят из SRS) :
1. Функциональные требования - в виде ВИ, т.е. пользовательских требований. На первом этапе только сами ВИ и их краткое описание, далее заполняем всю спецификацию
2. Не функциональные требования и ограничения описываем в виде одного-двух предложений
3. Дополняем диаграммой ВИ, которая называется "функциональная модель Системы"
4. Дополняем диаграммой бизнес сущностей - "Структурная модель Системы"
5. Каждый ВИ может быть дополнителнен макетом формы
6. БПравила описываем либо отдельно в каждом ВИ, либо (и) в отдельной секции.
7. После рекомендации Юрия, добавлю еще секцию - "Доп. функц. требования"
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Как Вы описываете требования к ПО? Ответ #4 : 05 Марта 2007, 18:59:11
Саша, нужно смотреть конкретно что за проект и что за юзкейсы, чтобы можно было действительно рекмендовать добавить дополнительную секцию. Вполне разумный подход -- не описанные требования (функц. и нефункц.)  описывать в другом артефакте (как это в RUP сделано) и трассировать на UC, в случае связки.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Как Вы описываете требования к ПО? Ответ #5 : 05 Марта 2007, 19:11:37
Саша, нужно смотреть конкретно что за проект и что за юзкейсы, чтобы можно было действительно рекмендовать добавить дополнительную секцию.
Это понятно, что если надо, то добавляем, если нет, то не добавляем. В принципе, у меня все функц. требования укладываются в ВИ и БПравила. Просто взял твою рекомендацию на заметку.

Вполне разумный подход -- не описанные требования (функц. и нефункц.)  описывать в другом артефакте (как это в RUP сделано) и трассировать на UC, в случае связки.
Это да, но не прижилось у нас как-то использование RMS (requirements management system), т.к. бОльшая часть людей пишут спеки как попало ...
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Как Вы описываете требования к ПО? Ответ #6 : 05 Марта 2007, 19:12:20
Если нет контрактных ограничений на формат документации требований, то я предпочитаю для нового проекта сначала написать Vision, где явно сформулировать какие бизнес-проблемы будут решены этим проектом (суть бизнес-требования), описать стейкхолдеров и софрмулировать основные фичи системы. При "идеальном" проекте, провязываются фичи с бизнес-требованиями. Рисуем контекстную диаграмму, чтобы определить опять-таки общие границы. И озвучиваем предположения которые делаем, вместе с ограничениями и обещаниями (по срокам, например)
Далее -- юзкейсы (если они применимы). Степень детализации зависит от конкретного проекта. Когда очень поверхностно, просто чтобы зафиксировать concept of operations, но тогда в SRS делаем более детальную проработку на уровне функциональных требований. А когда и достаточно детально, тогда имеет смысл использовать Supplementary Spec. а не SRS. А иногда, если и так все понятно ;-), ограничиваемся только юзкейсами. Повторюсь, что зависит от конкретного проекта.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Как Вы описываете требования к ПО? Ответ #7 : 25 Февраля 2009, 11:26:28
А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...



Re: Как Вы описываете требования к ПО? Ответ #8 : 25 Февраля 2009, 12:38:27
А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...

anastazya, а Вы в какой области работаете? Адаптируете и внедряете какие-то бизнес-системы других производителей, или работаете аналитиком в компании, разрабатывающей собственный софт?
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Как Вы описываете требования к ПО? Ответ #9 : 25 Февраля 2009, 12:53:59
greesha, разрабатывающей собственный софт



Re: Как Вы описываете требования к ПО? Ответ #10 : 25 Февраля 2009, 13:11:19
ida, а как спец по функ. дизайну поймет какие реквизиты на форму надо помещать, если я их не укажу? Если для заполнения определенных реквизитов нужны определенные правила заполнения? Вот что мне хотелось бы знать
« Последнее редактирование: 25 Февраля 2009, 14:29:43 от anastazya »



Re: Как Вы описываете требования к ПО? Ответ #11 : 25 Февраля 2009, 15:36:39
А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...

Можно описать не поля форм, а структуры данных в виде словаря данных (по Вигерсу), где описывается некая сущность и ее "информационный состав" - суть ее свойства (в терминах OOP). Например:
Клиент = ФИО {текст; required}
+ Адрес {текст; required}
+ Год рождения {текст; required}
+ Паспорт {текст; required}
+ Девичья фамилия матери {текст;}
+ Кличка собаки {текст;}
+ ...

тем самым вы четко даете понять на раннем этапе, какая информация о Клиенте в контексте вашего домена важна ...
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Как Вы описываете требования к ПО? Ответ #12 : 25 Февраля 2009, 16:35:18
Видел разные ТЗ. В том числе со скриншотами форм и текстом примерно таким: "Поля формы такой-то должны быть как на рисунке N". Допускаю, что для каких-то ситуаций это вполне приемлемо.
Вообще, считается, что чем больше деталей технической реализации прописать в ТЗ, тем проще будет потом разработчикам. Т.е. в основном тут идет компромисс со сроками и с желанием заказчика. Если заказчик не против и сроки позволяют, то почему бы не написать ТЗ с детальным описанием всех форм, полей, правил проверки и т.п.

В более типовой ситуации дизайн форм является все-таки предметом какого-то отдельного внутреннего документа разработки, а в согласуемом с заказчиком ТЗ эти сведения даются в более общем виде.



Re: Как Вы описываете требования к ПО? Ответ #13 : 25 Февраля 2009, 19:56:06
Можно в ТЗ описывать и данные, как сказал Юра, и формы, как Михаил, главное их разнести по разным документам или хотя бы по разделам, и из основных ФТ ссылаться на них
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Как Вы описываете требования к ПО? Ответ #14 : 25 Февраля 2009, 20:04:04
Можно в ТЗ описывать и данные, как сказал Юра, и формы, как Михаил, главное их разнести по разным документам или хотя бы по разделам, и из основных ФТ ссылаться на них
Мы на проекте пишем ВИ, далее все сущности описываем как сказал Юрий, с атрибутами и ограничениями, выдирая сущности из бизнеса или ВИ.
Далее на основе все тех же ВИ рисуем прототипы GUI - в описании полей даем ссылки на атрибуты сущностей.
+ трассировка от ВИ к сущностям и от ВИ к гуям.
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19