Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Сообщения - ilita

Страницы: 1
1
Спасибо за ответы, общая картина понятна. Мне импонирует ответ LDV
детализация - это не "внутреннее" ТЗ

Интересно было бы продолжить список ситуаций в которых необходимо именно "внутреннее" ТЗ (а не более детальный\архитектурный документ) т.е. аналогичных этой:
наличие нескольких заказчиков на общий продукт, который имеет единое ядро - "внутреннее" ТЗ

Я могу придумать только вырожденный случай: если "внешнего" (передающегося заказчику) ТЗ по каким-то причинам нет, документация, по которой будет вестись разработка, автоматически становится "внутренней".

2
В теме "Функционал, не описанный в требованиях" упоминается "внутренне" ТЗ:

Наживочная функциональность должна быть ... отражена во внутренних ТЗ, которые заказчику не передаются.

Поделитесь опытом: часто ли для реальных проектов (в предположении, что "внешнее" ТЗ существует) пишутся такие "внутренние" документы? Каковы их главные отличия от "внешних"? В каких ситуациях "внутренние" ТЗ наиболее полезны?

3
maksiq, да, интересно. Напишите подробней, пожалуйста!

4
Спасибо за ответы :)
Посмотрела Корбена, к вопросу действительно лучше подходить учитывая уровни. В глоссарии есть практически готовый вариант ответа (термин "уровень"):

Цитировать

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

Вариант использования уровня цели пользователя описывает достижение основным действующим лицом определенной и непосредственной цели. Он обычно выполняется одним основным действующим лицом за один сеанс продолжительностью от 2 до 20 мин (или меньше, если основным действующим лицом является компьютер). Далее основное действующее лицо может продолжить работу с друrими целями.


5
В поисках мудрости, связанной с вариантами использования, на просторах интернета наткнулась на вот такой вопрос (из списка для собеседования на должность аналитика):

Как долго может длиться экземпляр варианта использования до достижения своей цели? В оригинале - "How long (time/calendar) may an instantiated use case run before it could complete its goal?"

Первое, что пришло в голову - "столько, сколько нужно", но хорошего аргументированного ответа я придумать не смогла. Как бы Вы ответили на этот вопрос?

6
Всем большое спасибо за ответы, основная идея мне понятна. Попробую сделать прототип или какие-нибудь другие вспомогательные документы в дополнение к подробной спецификации (ее не разбирающемуся читателю читать все-таки придется, т.к. ему нужно ее подписывать).

7
Здравствуйте!

Вопрос: как писать спецификацию требований, чтобы она была понятна не только технически подкованным, но и не очень разбирающимся читателям?
Мне пришло в голову 2 варианта, но оба кажутся не очень удачными:

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

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

Хотелось бы услышать мнения на этот счет.

Страницы: 1