Документация требований wiki




Главная   Форумы   Общие вопросы и обсуждения   Документация требований wiki

В теме 3 ответа, и 2 участника, последнее обновление сделано пользователем Аватар (Melissa) Надежда Тарасюк 1 мес. назад.

Показано 4 ответа - от 1 до 4 (всего 4)
  • Автор
    Сообщения
  • 28.11.2016 в 17:41 # 18246
    Аватар (Lamp Bear)
    Lamp Bear
    Подписчик
    Добрый день, коллеги.

    Не так давно работаю непосредственно системным аналитиком (до этого занимался внедрением и поддержкой ИС), поэтому весьма плаваю в предметной области.

    Требуется сделать документацию в wiki для одной объемной сущности ИС. Проектная команда работает по скрам или его подобию:) Сейчас нет единого стандарта и мне необходимо все привести к одной форме представления требований в том числе с использованием диаграмм.

    Каким образом рекомендуете представить документацию? Благодарю.

    Поделиться:

    Цитировать

    22.12.2016 в 19:30 # 18258
    Добрый день,

    Принципиально инструмент ведения документации (вики это или что-то другое) мало на что влияет.
    Оформляйте там требования так, как вы это делаете сейчас.

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

    Поделиться:

    Цитировать

    23.12.2016 в 12:59 # 18270
    Аватар (Lamp Bear)
    Lamp Bear
    Подписчик
    Добрый день.

    Надежда, благодарю за ваш развернутый ответ.
    В работе используем Jira+Confluence, именно последнюю я назвал wiki, по сути она и есть.

    Сейчас практикуем такой метод: большой эпик разбиваем на таски с user story и по пунктам описываем требования и добавляем табличку Атрибут(Поле)/Контрол/Тип данных/Валидация/Ошибки. От практики описания контролов сейчас решили отказаться,  если над задачей работает UX-специалист, то это его задача выбирать какие контролы, если нет, то разработчики. Для описания объемных сущностей использую диаграммы: классов и вариантов использования.

    В прошлом сообщении я не совсем корректно сформулировал вопрос.

    На самом деле он касается больше содержания описания требований.
    Переформулирую иначе, как лучше их формализировать, чтобы удовлетворить всех участников команды это разработчики, UX-designer, тестировщик?

    Поделиться:

    Цитировать

    23.12.2016 в 22:50 # 18272
    Добрый вечер,

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

    Поделиться:

    Цитировать

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

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