Есть самописная информационная система, одной торговой компании - ей (ИС) уже около 10 лет. Система достаточно велика, чтобы никто в отделе, не знал её полностью.

Сейчас описано и поддерживается в актуальном состоянии только назначение таблиц и полей в БД (процентов на 70-80).
Остальное описание системы предсталяет из себя разрозненные документы (описание отдельных бизнес-процессов, проектная документация по некоторым фичам, описание отдельных отчётов итд итп).
Много функционала вообще нигде не описано.

Руководством поставлена цель сделать систематическое описание этой системы, а затем поддерживать его в актуальном состоянии.

Интересно именно описание требований к системе, а не описание реализации. Т.е. по любой фиче в системе, любой разработчик, аналитик или тестер (а возможно и пользователь?) должен легко получить исчёрпывающую информацию о том для Чего и для Кого Это делалось и как Это должно себя вести.
Соответственно, когда делается новый проект любому было понятно, что в описании надо изменить, чтобы оно осталось актуальным.

Ещё одно ограничение: описание должно быть максимально постепенным, т.е. сразу всё описать по ресурсам не получится. Описание будет происходить несколько месяцев, практически в фоновом режиме.

Думаю, задача, мягко говоря, не нова.
Посоветуйте, какой-нибудь реалистичный, проверенных жизнью вариант.



* ARIS?
Сам я не специалист, но то что я видел разочаровало. Попытка писать в нём (не мной :) а специалистами) детальные требования к системе приводили к жутким макаронным диаграммам, где ничего не понятно.

* Написать ОченьБольшуюSRS
Возможно ещё ОченьБольшоеОписаниеВсехЮзКейсов ?
и Концепцию листов так на 80-100 ?

* Завести внутренний вики-ресурс ?
Опять таки вопрос,какая должна быть структура у этого ресурса

* Requisite Pro?

* Другие инструменты?

grexhide
...никогда не возникает таких задач, как переписать все глобально...
...для пущей подстраховки в случае сильной переделки - реализуются интеграционные интерфейсы...
...Программистам - так тем более -.... Или банально, или не понятно...

Вы не совсем о нашей ситуации говорите.

Постараюсь проиллюстрировать примером:
*Делаем Проект111 для бухгалтерии, одновременно хорошо описали несколько юз-кейсов и бизнес-правил о том как отдел закупки работает с таможней.

*Прошло полгода. Аналитик проекта111 уволился. Делаем проект222 для отдела закупок. Никому в голову не придёт искать что-то в проекте111. Всё требования начинаем писать с нуля.

*Прошёл год. Делаем проект111версия2. Тремя месяцами раньше в ходе реализации проекта 150 для фронт-офиса фичи по проекту111 подкорректировали. Информация об этом только в документации по проекту 150. Кроме этого по просьбе пользователей сделали 4 небольших доработки по проекту111. Информация об этом есть только в баг-трекере. Результат: собираем требования для проекта111версия2 практически с нуля.


Если конкретизировать, то основные потребители такой документации - аналитики.
Основная цель: повторное использование требований к ПО.
Ищется инструмент и\или методика.

Цели тотального отслеживания что на что влияет не стоит. Для этого есть методы уровня разработчиков.

Возможно есть цель иметь некий классификатор функционала, чтобы программисты могли на него ссылаться. Здесь я не очень уверен, покритикуйте.

Гликоген
Итак, я бы сделал в Access или другой подходящей среде быстрой разработки ИС для документирования ИС.
В виде нескольких сущностей, реляционно связанных между собой, и простеньких форм, обеспечивающих ввод/правку....
alex108
Есть "самописный" bug tracking, который тоже интегрируется с wiki.
Вообщем, пока очень даже устраивает...
Petro123
идти от "уборки мусора"... и ввести простейший Bug Tracker (напр. Mantis) .
Очень удобно слушать "мнения пользователей".
Баг трекер есть. Не помогает. Цель немного другая. (См. постом выше)

andbary Когда я сам, сталкнулся с подобной проблемой, быстро выяснилось, что:
1. Трудоемкость документирования сравнима с написанием новой системы.
2. Перед данным действом необходимо навести порядок, иначе придеться документировать "кучу мусора".
3. Проверить правильность документации не представляется возможным.
Я пошел по пути "уборки мусора"... До сих пор убираю
PS Документировать можно только основные процессы, все остальное в вашей ситуации не имеет смысла. alex108...
Пытаюсь использовать локальную wiki-документацию (pmWiki). Наполнение происходит постепенно и постоянно.
Документы привязаны к подсистемам и режимам с online-доступом. Документация пишется как для пользователя, так и для разработчика...
Alexey Kudinov...
У нас когда-то чем-то аналогичным занимался специально выделенный человек и это было одной из его должностных обязанностей.
При этом
- код изначально был отлично документирован.
- люди, которые "знают все" были доступны.
Как результат, был описан основной функционал и взаимосвязи в системе. Но далеко не все. Petro123... поддержание порядка "в голове" или "на бумаге" бОльшой системы зависит от качества характера и ... желания руководства.
Т.е. идти от "уборки мусора"...
Очень удобно слушать "мнения пользователей".Как вы думаете цель повторного использования ранее собранных требований реалистична? Возможно это утопия на любом инструментальном средстве?

модПроблема действительно серьезная. Лично я пришел к таким выводам:
1. Для конечного пользователя - демо реальной системы с кратким описанием не очевидных моментов ("Руководство пользователя").
2. Для разработчика - исходники с коментариями того, что также не очевидно.
Т.е. лучшее описание системы - это она сама.
У нас есть ещё один класс заинтересованных лиц - аналитики.