В теме 9 ответов, и 3 участника, последнее обновление сделано пользователем 
Belle Morte 13 г, 7 мес. назад.
-
Сообщения
-
Вычитал в книге, что есть С-требования (пользовательские требования) и D-требования (для разработчиков).
Что вы показываете заказчику, а что разработке? Одно и тоже или разные документы?
и тишина….Похожую темы не нашёл. Если есть похожая тема, то мою тему можно подклеить к оной.
Моё первое SRS было рассчитано только на разработку, а теперь надо будет и с заказчиком как то быть. Всё пихать в один SRS?Нет времени на развернутый ответ…
Не знаю, на какую книгу вы ссылаетесь, но если это тиипчное деление требований на, помимо других, пользовательские и функциональные (http://analyst.by/forum/rabota-s-trebovaniyami/classifikaciya-trebovanii), то ответ будет немного не такой, как вы ожидаете: функциональные требования, и только они, имеют конечный смысл, так как определяют функционирование проектируемой системы.
Пользовательские требования — это то, что вы получаете на вход. По сути, их единственное предназначение — быть проанализированными вами, после чего их можно отправить в архив. SRS содержит функциональные требования (и отчасти требования бизнес-уровня).Герыч все правильно написал, добавлю немного от себя.
Документ создается один. Правда, некоторые разделы в нем требует особого внимания со стороны заказчика, у меня это, как правило: бизнес-правила, use cases и макеты пользовательского интерфейса. Перечисленные разделы я стараюсь обсуждать с заказчиками отдельно, чтобы они точно их заметили и поняли, иначе в общем документе они могут потеряться. Хорошо работают для этого также динамические прототипы.
В то же время некоторые технические подробности (например, маппинг на базу данных или подробное описание поведения всех элементов управления) для заказчика интереса чаще всего не представляют. Это значит, что при чтении документа скорее всего эти подробности пропустят. Но это не значит, что заказчику не надо их показывать или что для него надо создавать отдельный документ.В общем делать сразу ТЗ для заказчика и SRS для разработки (писали про это здесь) это будет неправильно, да? Мне как начинающему это тяжело будет.Нет времени на развернутый ответ…
Я могу подождать
Не знаю, на какую книгу вы ссылаетесь,
Извиняюсь, книга «Технология разработки программного обеспечения» Эрик Дж. Брауде, 2004. – 655 с.: ил
В общем там всё в одном SRS. Надо будет ещё полистать книжку и освежить инфу, а то она большая…
но если это тиипчное деление требований на, помимо других, пользовательские и функциональные (/forum/rabota-s-trebovaniyami/classifikaciya-trebovanii), то ответ будет немного не такой, как вы ожидаете: функциональные требования, и только они, имеют конечный смысл, так как определяют функционирование проектируемой системы.
Пользовательские требования — это то, что вы [u]получаете на вход[/u]. По сути, их единственное предназначение — быть проанализированными вами, после чего их можно отправить в архив. SRS содержит функциональные требования (и отчасти требования бизнес-уровня).Если пользовательские требования исключить из SRS, то от документа SRS заказчику мало будет толку. В SRS пользовательские требования можно представить в виде диаграмм пользовательских историй/сценариев, да?
Документ создается один.
Ясно.
Правда, некоторые разделы в нем требует особого внимания со стороны заказчика, у меня это, как правило: бизнес-правила, use cases и макеты пользовательского интерфейса. Перечисленные разделы я стараюсь обсуждать с заказчиками отдельно, чтобы они точно их заметили и поняли, иначе в общем документе они могут потеряться.
О, это важно! Буду так делать.
Хорошо работают для этого также динамические прототипы.
Что сие такое?
[quote="Belle Morte"]
Хорошо работают для этого также динамические прототипы.Что сие такое?
[/quote]Советую почитать вот эту тему, а также статью про создание прототипа analyst.by. В статье есть ссылка на получившийся прототип в html формате, так что лучше один раз посмотреть, сразу станет понятно, о чем речь.
Советую почитать [url=http://analyst.by/forum/instrumentarii-i-sredstva/dinahmicheskie-prototipy-interfeisov]вот эту тему[/url], а также [url=http://www.analyst.by/articles/axureanalystbyprototype]статью про создание прототипа analyst.by[/url]. В статье есть ссылка на получившийся прототип в html формате, так что лучше один раз посмотреть, сразу станет понятно, о чем речь.
Вы предвосхитили мою следующую тему по созданию примеров графических пользовательских интерфейсов и чем их создавать!
И ещё вопросик: а картинки примеров пользовательских интерфейсов помещаются в SRS?
Вы предвосхитили мою следующую тему по созданию примеров графических пользовательских интерфейсов и чем их создавать!
Вот об этом можно почитать здесь.
И ещё вопросик: а картинки примеров пользовательских интерфейсов помещаются в SRS?
Макеты пользовательских интерфейсов обязательно помещаются в SRS, также в SRS описываются все элементы управления, которые есть на этих макетах (название, тип, при каких условиях видимо, обязательно для заполнения, редактируемо, каков формат, возможные значения, поведение и т.д. и т.п.). Можно, конечно, обойтись только картинками, но, как показывает практика, это создаст дополнительные трудности при разработке и тестировании.
Для того, чтобы связать все эти макеты между собой, также рисуют карты сайта или схемы навигации.
Вы должны авторизироваться для ответа в этой теме.
