В теме 6 ответов, и 3 участника, последнее обновление сделано пользователем 
Snowball 14 г, 2 мес. назад.
-
Сообщения
-
Этот вопрос возник из разветвления другой темы про юз-кейсы.
В оригинале он звучит вот так:А как по вашему, в каком разделе SRS (спецификации требований) можно поместить скрины и таблицы данных?
Сейчас мы действуем по общепринятому стандарту IEEE 830-1998, но в нем, как мне кажется, очень большая свобода для маневров, в отличие от ГОСТов на создание ТЗ или ТП.
И поэтому мне хотелось бы знать, как действует большинство, ну так сказать быть в мейнстриме.
С уважением.Первый ответ:
скрины — External Interface Requirements -> User Interfaces или в Appendix, а по ходу документа ссылки в Appendix
таблицы данных — поясните, что имелось в виду.. если это таблицы с уже готовыми данными для использования, то это могут быть и Business Rules и Appendix.Продолжаем тему здесь (:
Да, свобода для маневров там есть. Ну так это ж и хорошо
Создайте, к примеру, кастомный раздел UI Overview и помещайте туда вместе с детальным описанием контролов.
Про таблицы данных я тоже не понял. Если имеется в виду описание схемы БД, то имхо это вообще не в SRS.Спасибо.
Возможно, мне бы даже хотелось расширить тему:
кто из участников имеет в своем активе наработок такую структуру SRS, которую считает ну … венцом своего творчества.
Которая бы охватывала все нужное разработчику: и варианты использования, и скрины, и таблицы метаданных, и все 5 видов архитектур, и при этом была бы ясной, взаимоувязанной и не эклектичной.
Свобода маневров в стандарте должна ведь рано или поздно привести хорошего технического писателя к выработке какой-то авторской концепции, которую он считает максимально универсальной и в то же время гибкой.
Честно говоря, немного стесняюсь своего вопросаВот только не надо стесняться
Абсолютно логичный вопрос. Да и какая разница, будь он даже неправильным? Все мы здесь именно и спрашиваем то, что не знаем.
Насчет SRS покопайтесь здесь: http://analyst.by/forum/dokumentaciya/kto-mozhet-podelitsya-shablonom-srs
Насчет охвата того, что нужно разработчику: вы уверены, что стоит пихать в один док требования и аспекты дизайна?Насчет охвата того, что нужно разработчику: вы уверены, что стоит пихать в один док требования и аспекты дизайна?
Конечно, неуверены. Хотя что понимается под аспектами дизайна? Имеется ли в виду дизайн как калька английского design или это то, что принято понимать под внешним дизайном.
Мне бы хотелось все-таки узнать, кто из аналитиков как расширил (или наоборот, сузил или даже интерполировал что ли) шаблон SRS, чтобы охватить все, что нужно на его взгляд разработчику, и за что его — аналитика — эти самые разработчики теперь носят на руках
. За ссылки на шаблоны большое спасибо, мы тут их с удовольствием и благодарностью изучаем и разбираем.
Да, дизайн как калька от design — то бишь, архитектуры, схемы данных, code conventions и другие аспекты реализации.
В принципе, по сути нет разницы куда вы это все поместите — хоть назовите документ "All Requirements" и размещайте там абсолютно все, что вы хотите донести до разработчиков. Я думаю, что правильным решением будет — делайте так, как удобнее для вас, команды и остальных стейкхолдеров. Учтите только, что если вам важен авторитет вас как аналитика в лице заказчика или если вы хотите сами развиваться и следовать неким правилам и принятым нормам, то стоило бы вести несколько различных документов, описывающих систему с разных сторон. Для этого я вам порекомендовал бы почитать вот это: http://analyst.by/forum/dokumentaciya/vidy-dokumentacii-razrabyvaemoi-analitikami. Что касается, непосредственно, аспектов разработки — есть Software Design Document, в который и стоит помещать всю выпоумянутую информацию. Вот только не факт, что это нужно делать вам, как аналитику требований (если вы им являетесь)…Что касается, непосредственно, аспектов разработки — есть Software Design Document, в который и стоит помещать всю выпоумянутую информацию.
Спасибо. На вашем же форуме обнаружили шаблон этого документа, любезно опубликованный Belle Morte, и действительно, тогда мой вопрос практически снимается. Поскольку вся эта эклектика, содержащая и скрины, и видение архитектуры, и таблицы данных, охватывается рамками именно этого документа (в частности, для скринов — пожалуйте, раздел HUMAN INTERFACE DESIGN, для таблиц данных — вот вам Data Description).
В общем еще раз большое спасибо, действительно, нужно вводить еще один документ в дело, хотя как правило, мы привыкли к такому набору документов: техническое задание, пакет документов технического проекта (пояснительная записка, перечни входных выходных данных, постановка задачи etc) и — несколько особняком — спецификация требований для разработчиков.
Вы должны авторизироваться для ответа в этой теме.
