В каком разделе SRS можно поместить скрины и таблицы данных?




В теме 6 ответов, и 3 участника, последнее обновление сделано пользователем Аватар (Snowball) Snowball 6 г, 11 мес. назад.

Показано 7 ответов - от 1 до 7 (всего 7)
  • Автор
    Сообщения
  • 24.09.2010 в 10:46 # 5834
    Этот вопрос возник из разветвления другой темы про юз-кейсы.
    В оригинале он звучит вот так:

    А как по вашему, в каком разделе SRS (спецификации требований) можно поместить скрины и таблицы данных?
    Сейчас мы действуем по общепринятому стандарту IEEE 830-1998, но в нем, как мне кажется, очень большая свобода для маневров, в отличие от ГОСТов на создание ТЗ или ТП.
    И поэтому мне хотелось бы знать, как действует большинство, ну так сказать быть в мейнстриме.
    С уважением.

    Первый ответ:

    скрины — External Interface Requirements -> User Interfaces или в Appendix, а по ходу документа ссылки в Appendix
    таблицы данных — поясните, что имелось в виду.. если это таблицы с уже готовыми данными для использования, то это могут быть и Business Rules и Appendix.

    Продолжаем тему здесь (:

    Поделиться:

    Цитировать

    24.09.2010 в 10:53 # 5835
    Да, свобода для маневров там есть. Ну так это ж и хорошо :)
    Создайте, к примеру, кастомный раздел UI Overview и помещайте туда вместе с детальным описанием контролов.
    Про таблицы данных я тоже не понял. Если имеется в виду описание схемы БД, то имхо это вообще не в SRS.
    Поделиться:

    Цитировать

    24.09.2010 в 11:34 # 5836
    Аватар (Snowball)
    Snowball
    Подписчик
    Спасибо.
    Возможно, мне бы даже хотелось расширить тему:
    кто из участников имеет в своем активе наработок такую структуру SRS, которую считает ну … венцом своего творчества.
    Которая бы охватывала все нужное разработчику: и варианты использования, и скрины, и таблицы метаданных, и все 5 видов архитектур, и при этом была бы ясной, взаимоувязанной и не эклектичной.
    Свобода маневров в стандарте должна ведь рано или поздно привести хорошего технического писателя к выработке какой-то авторской концепции, которую он считает максимально универсальной и в то же время гибкой.
    Честно говоря, немного стесняюсь своего вопроса :)
    Поделиться:

    Цитировать

    24.09.2010 в 11:38 # 5837
    Вот только не надо стесняться :wink: Абсолютно логичный вопрос. Да и какая разница, будь он даже неправильным? Все мы здесь именно и спрашиваем то, что не знаем.
    Насчет SRS покопайтесь здесь: http://analyst.by/forum/dokumentaciya/kto-mozhet-podelitsya-shablonom-srs
    Насчет охвата того, что нужно разработчику: вы уверены, что стоит пихать в один док требования и аспекты дизайна?
    Поделиться:

    Цитировать

    24.09.2010 в 13:32 # 5838
    Аватар (Snowball)
    Snowball
    Подписчик
    Насчет охвата того, что нужно разработчику: вы уверены, что стоит пихать в один док требования и аспекты дизайна?

    Конечно, неуверены. Хотя что понимается под аспектами дизайна? Имеется ли в виду дизайн как калька английского design или это то, что принято понимать под внешним дизайном.

    Мне бы хотелось все-таки узнать, кто из аналитиков как расширил (или наоборот, сузил или даже интерполировал что ли) шаблон SRS, чтобы охватить все, что нужно на его взгляд разработчику, и за что его — аналитика — эти самые разработчики теперь носят на руках :).

    За ссылки на шаблоны большое спасибо, мы тут их с удовольствием и благодарностью изучаем и разбираем.

    Поделиться:

    Цитировать

    24.09.2010 в 14:23 # 5839
    Да, дизайн как калька от design — то бишь, архитектуры, схемы данных, code conventions и другие аспекты реализации.
    В принципе, по сути нет разницы куда вы это все поместите — хоть назовите документ "All Requirements" и размещайте там абсолютно все, что вы хотите донести до разработчиков. Я думаю, что правильным решением будет — делайте так, как удобнее для вас, команды и остальных стейкхолдеров. Учтите только, что если вам важен авторитет вас как аналитика в лице заказчика или если вы хотите сами развиваться и следовать неким правилам и принятым нормам, то стоило бы вести несколько различных документов, описывающих систему с разных сторон. Для этого я вам порекомендовал бы почитать вот это: http://analyst.by/forum/dokumentaciya/vidy-dokumentacii-razrabyvaemoi-analitikami. Что касается, непосредственно, аспектов разработки — есть Software Design Document, в который и стоит помещать всю выпоумянутую информацию. Вот только не факт, что это нужно делать вам, как аналитику требований (если вы им являетесь)…
    Поделиться:

    Цитировать

    25.09.2010 в 08:58 # 5840
    Аватар (Snowball)
    Snowball
    Подписчик
    Что касается, непосредственно, аспектов разработки — есть Software Design Document, в который и стоит помещать всю выпоумянутую информацию.

    Спасибо. На вашем же форуме обнаружили шаблон этого документа, любезно опубликованный Belle Morte, и действительно, тогда мой вопрос практически снимается. Поскольку вся эта эклектика, содержащая и скрины, и видение архитектуры, и таблицы данных, охватывается рамками именно этого документа (в частности, для скринов — пожалуйте, раздел HUMAN INTERFACE DESIGN, для таблиц данных — вот вам Data Description).
    В общем еще раз большое спасибо, действительно, нужно вводить еще один документ в дело, хотя как правило, мы привыкли к такому набору документов: техническое задание, пакет документов технического проекта (пояснительная записка, перечни входных выходных данных, постановка задачи etc) и — несколько особняком — спецификация требований для разработчиков.

    Поделиться:

    Цитировать

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

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