В теме 40 ответов, и 7 участников, последнее обновление сделано пользователем 
Андрей В. 13 г, 5 мес. назад.
-
Сообщения
-
Не хочу показаться грубой
, но гугл знает все. Пояснение каждого вида займет много времени. Такие вопросы лучше обсуждать устно с коллегами.
Возможно Вам будет более полезен следующий шаблон.Посмотрите выложенные на форме [url=http://analyst.by/forum/dokumentaciya/kto-mozhet-podelitsya-shablonom-srs]темплейты спек[/url]. Возможно, станет понятнее.
Шаблоны очень полезны! Благодарю.
У Вас получается такое дерево, что требования не сгруппированы правильно.
Слишком много группировок
Спеки вида "Система должна быть такой, а потом такой и еще такой" в конечном итоге получаются нечитабильными.
Да. Нечитабельно.
Старался разделить на модули. Модули в свою очередь разбиваются на подмодули…. поэтому так много группировок.Я использую несколько подходов в группировке требований:
-От интерфейса, если система простая типа информационного сайта.
-По модулям. В модули объединяю подобные друг на друга функции (типа "бухгалтерсикий учет", "учет данных сотрудников" и т.п.).
-По классам пользователей, если у пользователей различный функции в системе.Требования к интерфейсу вынес в нефункциональным требования.
Модули в функциональных у меня. Я их там разбиваю на детальные требования — вплоть до какие колонки и строки в таблицах должны быть.
Класс пользователей всегда один — просто пользовательВаша блок схема вполне может оказаться сценарием использования и быть частью пользовательских требований.
Вас понял. Идея понравилось. Это и будет частью ПТ. Из схемы будут вытекать системные требования (точнее функциональные).
Не хочу показаться грубой
, но гугл знает все.
Эххх…..
Пояснение каждого вида займет много времени. Такие вопросы лучше обсуждать устно с коллегами.
Нет таких людей
Возможно Вам будет более полезен следующий [url=http://www.csc.villanova.edu/~tway/courses/csc4181/srs_template-1.doc]шаблон[/url].
На предыдущем месте использовали srs. Тоже склоняюсь к нему. Сначала в DOORS работает, а за тем таблицу требований буду вставлять в srs_template.
Требования к интерфейсу вынес в нефункциональным требования.
Это не совсем правильно (хотя смотря что там у Вас в требованиях). Иногда динамические взаимодействие очень даже функциональные требования.
А вообще, если не трудно (секретно), в 2х словах расскажите о системе. Что за тип системы, какая бизнес цель и т.п.?
Andre, я бы вам на перспективу посоветовал либо некие курсы тематические пройти, либо банально подружиться с опытными аналитиками и первое время работать под их руководством (если же у вас в компании реально найти сеньеров в помощь, то это просто a must). Из того, что я успел заметить, у вас отсутствуют многие базовые аспекты восприятия процесса разработки проекта и работы с требованиями. Вы пытаетесь влезть глубоко в детали, хотя начинать вам нужно абсолютно не с этого. Если у вас безвыходная ситуация, то конечно участники форума вам охотно помогут… но из того, что я пока вижу, разработка вашего проекта будет далека от эффективной. У вас координатор, которому небезразличен ход проекта, есть?[quote="andre"]
Требования к интерфейсу вынес в нефункциональным требования.Это не совсем правильно (хотя смотря что там у Вас в требованиях). Иногда динамические взаимодействие очень даже функциональные требования.
[/quote]
Хм…. посмотрим. Пока основу бы описать.А вообще, если не трудно (секретно), в 2х словах расскажите о системе. Что за тип системы, какая бизнес цель и т.п.?
Цели? Даже заказчик не может толком сказать
Если в общем, то получаем данные на свой сервер с разных мест. Программа клиент? которая красиво представляет данные с нашего сервера — таблицы, графики и пр. Всякие анализы будем проводить этих данных.Andre, я бы вам на перспективу посоветовал либо некие курсы тематические пройти,
Курсы только в перспективе (и то под вопросом
) . Руководство обещает курсы оплатить, но скорее всего это будет в Москве. Я из Нижнего Новгорода и здесь вроде таких курсов нет. По курсам буду очень благодарен за информацию.Книга "Scrum и XP: заметки с передовой" от Хенрик Книберг очень понравилась. Мне хочет попробовать внедрить его.
Прочитал еще «Разработка и управление требованиями. Практическое руководство пользователя. (Второе издание) Элизабет Халл. Кен Джексон. Джереми Дик 2005»
Сейчас просто физически нет время на чтение книг по требованиям. Все время уходит на изучение предметной области и написание требований ибо скоро показывать результат. Через недельку надеюсь будет время на чтение.либо банально подружиться с опытными аналитиками и первое время работать под их руководством (если же у вас в компании реально найти сеньеров в помощь, то это просто a must).
Нет таких людей. Я типа самый опытный вот и поставили
Вот с вами дружить начинаю
Книги конечно хорошо, но вот к практике как это всем пременить… Был бы человек который показал бы как это все в жизни бывает, а то жизнь далеко от книжек.Из того, что я успел заметить, у вас отсутствуют многие базовые аспекты восприятия процесса разработки проекта и работы с требованиями.
На прошлом месте. Руководитель проекта собирал данные от продажников, заказчика кое-как формировал в требования в функциональные, производительность + еще что то было. Общую архитектуру набрасывал и все. В шаблоне SRS делали, до DD (детал дизайн) и тестовых сценариев не доходило. Прототипа и общего интерфейса не было.
Вы пытаетесь влезть глубоко в детали, хотя начинать вам нужно абсолютно не с этого. Если у вас безвыходная ситуация, то конечно участники форума вам охотно помогут… но из того, что я пока вижу, разработка вашего проекта будет далека от эффективной. У вас координатор, которому небезразличен ход проекта, есть?
В детали? Ну я должен в требованиях указать то какие таблица должны быть и по каким форумалам идет расчет графика.
На след недели буду показывать что я написал
Управления нет. Полный хаус. Все только-только начинают налаживать.Дело в том что заказчик то в очень общих чертах представляет что надо.
Ну тогда похоже корни следует искать в организации самого процесса. Я не хочу сказать, что вам стоит посылать на три буквы ваших руководителей, но к вам сейчас предъявляются слегка противоречивые требования, что стоило бы "ненавязчиво" эскалировать. Сочетание следующих фраз видится мне крайне опасным:Цели? Даже заказчик не может толком сказать
Вам обязательно надо узнать, для чего предназначена система и какой value она несет заказчику (и лучше это сделать поздно, чем никогда).
Сейчас просто физически нет время на чтение книг по требованиям. Все время уходит на изучение предметной области и написание требований ибо скоро показывать результат. Через недельку надеюсь будет время на чтение.
Управления нет. Полный хаус. Все только-только начинают налаживать.
То бишь, на проекте, который крайне сжат по срокам, нет как координирования, так и налаженного процесса работы с требованиями… Главное вам, конечно же, этот проект сейчас успешно закончить (пусть и кое-как..). Отталкивайтесь от цели "дать заказчику то, что он хочет любыми средствами в рамках бюджета и сроков", а не от цели "как правильно с точки зрения книг организовать процесс работы с требованиями". Потом, когда у вас будет время, ставьте процессы и изучайте практики. Сейчас же — доносите требования до команды хоть на салфетке, а заказчика пытайте как можно больше (неважно, насколько красиво вы ему сформулируете вопросы и как вы назовете формулу ему и команде, пусть хоть даже как usability требование) — главное, чтобы вы до конца поняли заказчика (его хотелку) и четко передали это команде.
Насчет эскалации я упомянул не зря.. Не дай бог, что пойдет не так (а признаки уже есть) — вы окажетесь одним из тех, на кого руководство покатит бочки. Да, ваша задача состоит в том, чтобы качественно делать работу, но сочетание того, что вы только начинающий + отсутствие управление + остутствие наработанных практик и помощи, как-то уже слишком.Цели? Даже заказчик не может толком сказать
Если в общем, то получаем данные на свой сервер с разных мест. Программа клиент? которая красиво представляет данные с нашего сервера — таблицы, графики и пр. Всякие анализы будем проводить этих данных.Советую, все-таки цели определить. Это просто супер-мега-обязательный шаг на пути успешного проекта (когда заказчик доволен).
Вопрос, а Вы используете какие-либо существующие/готовые технологии/тулы типа Data Warehousing/Microsoft Analysis Services/Excel/Power Pivot/Performance Point/Tableau/….?
Немного пьян ибо празднуем день Красной Армии, ой пардон…
В общем использую DOOS.
Ранее внедрил SVN и bugzilla. Сейчас вместо bugzilla внедрили JIRA.Почему DOORS? Книжка по требованиям описывают DOORS + руководство на русском. То что дорого это понятно, но пока выбираем-с. Всех с наступающим!
В четверг отвечу более подробно. Всем спасибо за внимание!
Ну тогда похоже корни следует искать в организации самого процесса.
))))))))))))))))))))))))))
процесса нет.процесса нет.
Ну, тогда надо его ставить. Если нету координатора/менеджера — ставить самому.
1. Определиться с формой общения с заказчиком (email, телефон, instant messenger)
2. Составить список первоначальных вопросов и назначить время встреч.
3. Собрать начальные требования и подготовить дальнейшие материалы и артефакты.
4. Выбрать способ/систему трекания задач (Team Foundation Server, Track Studio, Fazend Trac и т.д.)
5. Расписать дальнейшие действия/таски на себя и остальных членов команды
6. Назначить дальнейшие обсуждения с заказчиком
7. Постоянно составляйте список текущих задач и обновляйте его как можно чаще.Все собранные требования обязательно необходимо фиксировать и утверждать с заказчиком. Ставить процесс конечно думаю должен опытный человек и мне бы самому было сложно это сделать, но если у вас нету опытных сотрудников, способных вам помочь, ничего не поделаешь — придется самому.
Покопайте теорию, посоветуйтесь с проджект менеджерами или старшими аналитиками (не обязательно из вашей компании). Постарайтесь объяснить ситуацию начальству — расскажите, что проект идет не по тому пути, которому бы вам хотелось. Чем раньше вы обозначите проблему тем раньше ее начнут решать, возможно выделят вам подкрепление в виде вот такого аналитика
Gerych и essence так и не ответили! А сегодня так ждал вашего ответа.[quote="andre"]
процесса нет.Ну, тогда надо его ставить. Если нету координатора/менеджера — ставить самому.
[/quote]
Ни вопрос.
Пытался рабочий процесс поднять в разработке, но всем пофигу и начальник это го не понимает. Хотя SVN им понравилось, а вот bugzilla и jira не очень ибо писать надо.1. Определиться с формой общения с заказчиком (email, телефон, instant messenger)
У меня с заказчиком личное общение
2. Составить список первоначальных вопросов и назначить время встреч.
Вопросы беру с книжки telelogic, но они как то мало помогают. Что еще посоветуете?
3. Собрать начальные требования и подготовить дальнейшие материалы и артефакты.
Требований как таковых нет. Только общее описание… что за артефакты?
4. Выбрать способ/систему трекания задач (Team Foundation Server, Track Studio, Fazend Trac и т.д.)
TFS поднял, но что то больно крутая и дорогая система. В общем время в ней разобраться не было
но на виртуальнйо машине стоит.
JIRA есть, но чем она мне может помочь?5. Расписать дальнейшие действия/таски на себя и остальных членов команды
В команде аналитиков только я
6. Назначить дальнейшие обсуждения с заказчиком
Можно. Надо как то из заказчика выбивать, то что ему надо.
7. Постоянно составляйте список текущих задач и обновляйте его как можно чаще.
Задача одна — получить с заказчика, то что он хочет.
Все собранные требования обязательно необходимо фиксировать и утверждать с заказчиком. Ставить процесс конечно думаю должен опытный человек и мне бы самому было сложно это сделать, но если у вас нету опытных сотрудников, способных вам помочь, ничего не поделаешь — придется самому.
Процесс по сбору требований? Там в основном встречи с заказчиком и все. Вроде так? В конце согласование SRS к системе с заказчиком.
Покопайте теорию,
Какие книги посоветует?
Я сейчас в поисках платных курсов, но что то их мало и только в Москве.Посоветуйтесь с проджект менеджерами или старшими аналитиками (не обязательно из вашей компании).
У нас таких нет. А со стороны кто будет помогать?! И еще таких спецов найти надо.
Постарайтесь объяснить ситуацию начальству — расскажите, что проект идет не по тому пути, которому бы вам хотелось. Чем раньше вы обозначите проблему тем раньше ее начнут решать, возможно выделят вам подкрепление в виде вот такого аналитика
Подкрепления это я
Подкрепление подкреплению никто не будет выделять.
Вы должны авторизироваться для ответа в этой теме.
