Feedback Request: Книга «Идеальное ТЗ». Что внутри?
#1
Отправлено 05 декабря 2008 - 17:20
На какие вопросы вы бы хотели получить ответы в такого рода книге? О чём узнать?
Ориентировочная структура книги:
Идеальное ТЗ
на программу, информационную систему, веб-продукт
1. Для кого эта книга
2. Предисловие
Методы, методы, методы!
3. Каким бывает успех?
Проект, продукт, система
Бизнес, пользователь, разработчики
4. Выявляем интересы
Ожидания
Публичное
Скрытое
5. Формулируем проблему
Что сейчас?
Что потом?
Конфликты
6. Зри в корень!
Находим причины
7. Кладём цели
Деятельностный подход
Целевая ситуация
8. Исследования
Предметная область
Рынок
Деятельность бизнеса
Деятельность пользователей
9. Зачем нужна концепция
Ключевые свойства продукта
10. А теперь можно без ТЗ?
11. Хорошее ТЗ, плохое ТЗ
Контейнер
Свойства идеального документа
Почему идеального ТЗ не бывает
12. Всё понятно! Поехали! Типичные ошибки
Работа по шаблону
Скачки по уровням
ХЗ
Техпис
13. Как должны выглядеть требования?
Что и Как
Функции, функции и функции
Конец конвейера
Взаимодействия
Сценарии способов применения
Бизнес-правила
Атрибуты качества и ограничения
Иерархия требований и трассируемость
14. Шаблоны профилей качества
Категории систем
Аспекты качества
15. Моделирование системы
Белый ящик, чёрный ящик
Бизнес-архитектура, Техническая архитектура
16. Прототипирование
Модель навигации
Разработка макетов
17. Контроль реализации требований
Виды тестирования
Связь тестовых сценариев и сценариев способов применения
18. Изменения требований
Анализ влияния
Девалидация
19. Процесс
Принципы
Роли
Виды документов
Методы и лучшие практики
Цикл итерации
20. Проект
Где мы: Заказчик, Разработчик, Консультант
Выбор методов
Приложеньица
Профиль профессии «Бизнес-аналитик»
Профиль профессии «Системный аналитик»
Стандарты
Что читать
Инструменты
Словарь терминов
Ссылки
#2
Отправлено 03 мая 2009 - 05:57
Например, от Баранцева Алексея:
"Техническое задание в большей степени ориентировано на внутреннюю организацию системы, на её архитектуру, на то, как нужно делать систему, чтобы получилось то, что соответствует требованиям".
У меня предположение, что книга должна быть лаконичной и относительно краткой, как и само ТЗ, цитата из детской книги А. Курляндского "Прелестно":
"И так далее. На целую страницу. Не будем приводить весь текст полностью. О чем идет речь, Вы знаете, а бумага для книг все дорожает. Будем экономить. Тогда и наша книжка будет стоить дешевле".
Трудно судить о будущем творении только по названиям разделов и тезисам. Мое предложение не в экономии бумаги, а в согласованности качества и четкости содержания книги и конечного результата - идеального ТЗ.
А вопросов нет, увы.
С уважением, Vita
... you can learn from that too
#3
Отправлено 02 июня 2009 - 13:39
А по опыту работы: ТЗ должно содержать все основные моменты проектируемой системы, и как у нас говорили "ты, в итоге, должен ответить головой за каждое написанное слово в ТЗ" и каждое это слово должно быть дальше детально расписано в эскизном, техническом и т.д. проектах ну и реализовано в конце концов. :)
#4
Отправлено 04 июня 2009 - 17:31
классификация существующих. + и -. вот это:)
#5
Отправлено 10 июля 2009 - 13:04
#6
Отправлено 12 июля 2009 - 11:57
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#7
Отправлено 12 июля 2009 - 12:05
1) requirements, use-cases - тоже вид ТЗ либо промежуточная часть в процессе его создания
2) техническая сторона: ARIS'ы, IDEF'ы, UML'и и иже с ними должны быть (ИМХО) покрыты, хотя бы поверхностно.
3) судя по оглавлению, Вы ТЗ рассматриваете во многом оформительно-процессно, как статью :) Очень мало внимания уделено анализу (композиции там всякие, декомпозиции :))
4) надеюсь на глубокое рассмотрение в этой книге процесса согласования ТЗ - очень существенная часть работы аналитика, с которой часто бывают проблемы. Заказчик, стейкхолдер, разработчик - нюансы исследования их мнений и согласований с ними, способы преподнесения им информации
5) хотелось бы чтобы был освещён вопрос "авторизации" ТЗ. я видела ситуации, когда при хорошем ТЗ всё делали не по нему :) Но это близко к комментарию 4
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#8
Отправлено 09 января 2010 - 16:24
Детатализировать ТЗ можно практически до бесконечности, но должны же быть какие то рамки?
Зачем детализировать до бесконечности? Грамотному разработчику достаточно и обычного ТЗ.
#9
Отправлено 09 января 2010 - 22:01
Детатализировать ТЗ можно практически до бесконечности, но должны же быть какие то рамки?
Зачем детализировать до бесконечности? Грамотному разработчику достаточно и обычного ТЗ.
Начинающему грамотному разработчику достаточно и обычного ТЗ. Потом начинается опыт с "а ведь мы думали, что по-умолчанию..." и "но ведь любой дурак знает, что это работает именно вот так..."
Software Testing Glossary - простыми словами о непростых словах.
#10
Отправлено 11 января 2010 - 07:24
Детатализировать ТЗ можно практически до бесконечности, но должны же быть какие то рамки?
Зачем детализировать до бесконечности? Грамотному разработчику достаточно и обычного ТЗ.
Начинающему грамотному разработчику достаточно и обычного ТЗ. Потом начинается опыт с "а ведь мы думали, что по-умолчанию..." и "но ведь любой дурак знает, что это работает именно вот так..."
Мне понравилось выражение "начинающему грамотному разработчику".
Интересно стало -- знание особенностей предметной области входит в понятие "грамотный разработчик"? Или нет?
И что такое "обычное ТЗ"?
#11
Отправлено 11 января 2010 - 07:40
Я сейчас пишу книгу под условным названием «Идеальное ТЗ: Для программы, информационной системы, веб-продукта».
На какие вопросы вы бы хотели получить ответы в такого рода книге? О чём узнать?
Ориентировочная структура книги:
Идеальное ТЗ
на программу, информационную систему, веб-продукт
1. Для кого эта книга
2. Предисловие
Методы, методы, методы!
.....................................
Ссылки
У меня, как у потенциального покупателя - сразу вопрос.
А для каких именно программ?
И что такое - "информационная система"?
Что такое "автоматизированная система" и что должно быть в ТЗ на АС в общем определено.
#12
Отправлено 11 января 2010 - 08:44
знание особенностей предметной области входит в понятие "грамотный разработчик"? Или нет?
Разумеется, входит.
Под "грамотный" подразумевается некто, обладающий необходимыми знаниями и/или сведениями в определенной области труда. Истоковое значение термина подразумевает всего лишь умение читать и писать.
что такое "обычное ТЗ"?
Нетехническое, обще-зрительное описание функционала будущей программы. Содержит много "темных мест" и мало точности, зато много предположений по-умолчанию.
Является первым шагом к диалогу. Восприниматься в качестве "требований" может только при определенных попущениях.
Зачастую - источник раздражения и ненависти.
Software Testing Glossary - простыми словами о непростых словах.
#13
Отправлено 11 января 2010 - 11:17
1. Ясно. Спасибо.знание особенностей предметной области входит в понятие "грамотный разработчик"? Или нет?
Разумеется, входит.
Под "грамотный" подразумевается некто, обладающий необходимыми знаниями и/или сведениями в определенной области труда. Истоковое значение термина подразумевает всего лишь умение читать и писать.что такое "обычное ТЗ"?
Нетехническое, обще-зрительное описание функционала будущей программы. Содержит много "темных мест" и мало точности, зато много предположений по-умолчанию.
Является первым шагом к диалогу. Восприниматься в качестве "требований" может только при определенных попущениях.
Зачастую - источник раздражения и ненависти.
Пожалуй что только не в "опреленной области труда", а в "опреленной предметной сфере". Т.е. той сфере, для которой пишется ПО.
2. Понятно.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных