Вы разделяете требования для заказчика и для разработчика?




В теме 9 ответов, и 3 участника, последнее обновление сделано пользователем Аватар (Belle Morte) Belle Morte 13 г, 5 мес. назад.

Показано 10 ответов - от 1 до 10 (всего 10)
  • Автор
    Сообщения
  • 19.04.2011 в 17:49 # 5928
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    Вычитал в книге, что есть С-требования (пользовательские требования) и D-требования (для разработчиков).

    Что вы показываете заказчику, а что разработке? Одно и тоже или разные документы?

    Поделиться:

    Цитировать

    21.04.2011 в 14:11 # 5929
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    и тишина….

    Похожую темы не нашёл. Если есть похожая тема, то мою тему можно подклеить к оной.
    Моё первое SRS было рассчитано только на разработку, а теперь надо будет и с заказчиком как то быть. Всё пихать в один SRS?

    Поделиться:

    Цитировать

    21.04.2011 в 15:05 # 5930
    Нет времени на развернутый ответ…
    Не знаю, на какую книгу вы ссылаетесь, но если это тиипчное деление требований на, помимо других, пользовательские и функциональные (http://analyst.by/forum/rabota-s-trebovaniyami/classifikaciya-trebovanii), то ответ будет немного не такой, как вы ожидаете: функциональные требования, и только они, имеют конечный смысл, так как определяют функционирование проектируемой системы.
    Пользовательские требования — это то, что вы получаете на вход. По сути, их единственное предназначение — быть проанализированными вами, после чего их можно отправить в архив. SRS содержит функциональные требования (и отчасти требования бизнес-уровня).
    Поделиться:

    Цитировать

    21.04.2011 в 15:43 # 5931
    Аватар (Belle Morte)
    Belle Morte
    Участник
    Герыч все правильно написал, добавлю немного от себя.
    Документ создается один. Правда, некоторые разделы в нем требует особого внимания со стороны заказчика, у меня это, как правило: бизнес-правила, use cases и макеты пользовательского интерфейса. Перечисленные разделы я стараюсь обсуждать с заказчиками отдельно, чтобы они точно их заметили и поняли, иначе в общем документе они могут потеряться. Хорошо работают для этого также динамические прототипы.
    В то же время некоторые технические подробности (например, маппинг на базу данных или подробное описание поведения всех элементов управления) для заказчика интереса чаще всего не представляют. Это значит, что при чтении документа скорее всего эти подробности пропустят. Но это не значит, что заказчику не надо их показывать или что для него надо создавать отдельный документ.
    Поделиться:

    Цитировать

    22.04.2011 в 10:17 # 5932
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    В общем делать сразу ТЗ для заказчика и SRS для разработки (писали про это здесь) это будет неправильно, да? Мне как начинающему это тяжело будет.
    Поделиться:

    Цитировать

    22.04.2011 в 10:46 # 5933
    Аватар (Андрей В.)
    Андрей В.
    Подписчик

    Нет времени на развернутый ответ…

    Я могу подождать :)

    Не знаю, на какую книгу вы ссылаетесь,

    Извиняюсь, книга «Технология разработки программного обеспечения» Эрик Дж. Брауде, 2004. – 655 с.: ил

    В общем там всё в одном SRS. Надо будет ещё полистать книжку и освежить инфу, а то она большая… :)

    но если это тиипчное деление требований на, помимо других, пользовательские и функциональные (/forum/rabota-s-trebovaniyami/classifikaciya-trebovanii), то ответ будет немного не такой, как вы ожидаете: функциональные требования, и только они, имеют конечный смысл, так как определяют функционирование проектируемой системы.
    Пользовательские требования — это то, что вы [u]получаете на вход[/u]. По сути, их единственное предназначение — быть проанализированными вами, после чего их можно отправить в архив. SRS содержит функциональные требования (и отчасти требования бизнес-уровня).

    Если пользовательские требования исключить из SRS, то от документа SRS заказчику мало будет толку. В SRS пользовательские требования можно представить в виде диаграмм пользовательских историй/сценариев, да?

    Поделиться:

    Цитировать

    22.04.2011 в 10:57 # 5934
    Аватар (Андрей В.)
    Андрей В.
    Подписчик

    Документ создается один.

    Ясно.

    Правда, некоторые разделы в нем требует особого внимания со стороны заказчика, у меня это, как правило: бизнес-правила, use cases и макеты пользовательского интерфейса. Перечисленные разделы я стараюсь обсуждать с заказчиками отдельно, чтобы они точно их заметили и поняли, иначе в общем документе они могут потеряться.

    О, это важно! Буду так делать.

    Хорошо работают для этого также динамические прототипы.

    Что сие такое? :)

    Поделиться:

    Цитировать

    22.04.2011 в 13:23 # 5935
    Аватар (Belle Morte)
    Belle Morte
    Участник

    [quote="Belle Morte"]
    Хорошо работают для этого также динамические прототипы.

    Что сие такое? :)[/quote]

    Советую почитать вот эту тему, а также статью про создание прототипа analyst.by. В статье есть ссылка на получившийся прототип в html формате, так что лучше один раз посмотреть, сразу станет понятно, о чем речь.

    Поделиться:

    Цитировать

    22.04.2011 в 15:56 # 5936
    Аватар (Андрей В.)
    Андрей В.
    Подписчик

    Советую почитать [url=http://analyst.by/forum/instrumentarii-i-sredstva/dinahmicheskie-prototipy-interfeisov]вот эту тему[/url], а также [url=http://www.analyst.by/articles/axureanalystbyprototype]статью про создание прототипа analyst.by[/url]. В статье есть ссылка на получившийся прототип в html формате, так что лучше один раз посмотреть, сразу станет понятно, о чем речь.

    Вы предвосхитили мою следующую тему по созданию примеров графических пользовательских интерфейсов и чем их создавать! *THUMBS UP*

    И ещё вопросик: а картинки примеров пользовательских интерфейсов помещаются в SRS?

    Поделиться:

    Цитировать

    22.04.2011 в 16:09 # 5937
    Аватар (Belle Morte)
    Belle Morte
    Участник

    Вы предвосхитили мою следующую тему по созданию примеров графических пользовательских интерфейсов и чем их создавать! *THUMBS UP*

    Вот об этом можно почитать здесь.

    И ещё вопросик: а картинки примеров пользовательских интерфейсов помещаются в SRS?

    Макеты пользовательских интерфейсов обязательно помещаются в SRS, также в SRS описываются все элементы управления, которые есть на этих макетах (название, тип, при каких условиях видимо, обязательно для заполнения, редактируемо, каков формат, возможные значения, поведение и т.д. и т.п.). Можно, конечно, обойтись только картинками, но, как показывает практика, это создаст дополнительные трудности при разработке и тестировании.
    Для того, чтобы связать все эти макеты между собой, также рисуют карты сайта или схемы навигации.

    Поделиться:

    Цитировать

Показано 10 ответов - от 1 до 10 (всего 10)

Вы должны авторизироваться для ответа в этой теме.