В теме 3 ответа, и 2 участника, последнее обновление сделано пользователем 
Надежда Тарасюк 7 г, 11 мес. назад.
-
Сообщения
-
Добрый день, коллеги.
Не так давно работаю непосредственно системным аналитиком (до этого занимался внедрением и поддержкой ИС), поэтому весьма плаваю в предметной области.
Требуется сделать документацию в wiki для одной объемной сущности ИС. Проектная команда работает по скрам или его подобию:) Сейчас нет единого стандарта и мне необходимо все привести к одной форме представления требований в том числе с использованием диаграмм.
Каким образом рекомендуете представить документацию? Благодарю.
Добрый день,Принципиально инструмент ведения документации (вики это или что-то другое) мало на что влияет.
Оформляйте там требования так, как вы это делаете сейчас.Но с удобствами, которые позволяет вики (не знаю, какая система у вас, но для большинства знакомых мне вики это работает):
- информацию представлять не линейно (как в документе мс ворд), а иерархически (разделы — страницы — вложенные страницы)
- удобно линковать страницы вики (и требования таким образом) между собой тем самым помогая с трассировками
- более удобный поиск, чем просто в документе мс ворд
- ну и само собой, удобное онлайн многопользовательское редактирование, просмотр и хранение версий.Добрый день.Надежда, благодарю за ваш развернутый ответ.
В работе используем Jira+Confluence, именно последнюю я назвал wiki, по сути она и есть.Сейчас практикуем такой метод: большой эпик разбиваем на таски с user story и по пунктам описываем требования и добавляем табличку Атрибут(Поле)/Контрол/Тип данных/Валидация/Ошибки. От практики описания контролов сейчас решили отказаться, если над задачей работает UX-специалист, то это его задача выбирать какие контролы, если нет, то разработчики. Для описания объемных сущностей использую диаграммы: классов и вариантов использования.
В прошлом сообщении я не совсем корректно сформулировал вопрос.
На самом деле он касается больше содержания описания требований.
Переформулирую иначе, как лучше их формализировать, чтобы удовлетворить всех участников команды это разработчики, UX-designer, тестировщик?Добрый вечер,Давайте я еще раз переформулирую, чтобы наверняка понять вопрос.
Сейчас вы работаете так: «Большой эпик разбиваем на таски с user story и по пунктам описываем требования и добавляем табличку Атрибут(Поле)/Контрол/Тип данных/Валидация/Ошибки. Для описания объемных сущностей использую диаграммы: классов и вариантов использования.» Но хотите изменить такой подход к описанию требований. Я верно поняла?
Почему хотите изменить?
Какие есть пожелания по формату требований у команды разработки и тестирования, руководства и заказчика?
Что вас самого смущает в вашем текущем подходе?
Вы должны авторизироваться для ответа в этой теме.
