ТЗ php+ajax сайта

Как я понимаю ТС нужна некая среда, где можно было бы нарисовать интерфейс + некий функционал (выпад, меню, реакцию на определённое поведение и тд). Вот мне тоже интересно, только в приложении к декпоп-софту.

Что касается ТЗ (не важно, сайт или копка траншей) - не нужно заморачиваться на технология. Важно описать так как вы вы это видите и что хотите в результате.

Для сайтов очень полезно показать готовые реализации (ссылки) с пояснением что именно так или не так, как вы хотите.

Вот есть программка, может помочь в составлении ТЗ.

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

Вообще для разработки интерфейсов используются программы типа Denim http://dub.washington.edu:2007/denim/ Интерфейс немного непривычен, но в целом довольно интересная програмка. А если указывать, что аякс должен быть задействован, то мне было бы удобнее чтобы требуемый функционал в этом направлении был описан текстом.

У людей в голове каша. Фреймворки со средами разработки путают, ТЗ с брифингом...

По сабжу: Если стоит задача "наглядно" продемонстрировать клиенту интерфейс (на примере выпадающего меню), при этом не вдаваясь в реализацию, надо смотреть в сторону систем проектирования интерфейсов. Мне например нравится axure, но их полно.

Вот-вот. Для общего развития можно почитать.

Dreammaker, не стоит путать (и пугать) людей знанием программирования. В 99% знание неких терминов и основ программирования составителями ТЗ только путают разработчиков.

neolord, Dreammaker, спасибо за наколку. Теперь и я знаю в какую сторону копать.

SeoNizator,

Не совсем понял, что вы хотели сказать. То что я вас запутал? Или что?

бред полный. Может еще на что-то откроете глаза.

Понимаете, есть такое утверждение - объяснить может только то, кто сам понимает проблему. Насколько я понимаю, вы сами сейчас не очень понимаете что хотите. Совет. Возьмите поверпоинт и сделайте пошагово (слайд за слайдом) что вы хотите получить. Когда схема выстроится в Вашей голове и на экране - нормальный программист поймет.

Меня-то нет (я немного в программировании понимаю). Но вот составителей ТЗ - да :). (я пропустил слово. Читать нужно так: "... людей необходимостью знать программирование")

Эдак они ещё подумают, что и им нужно учить программирование, чтобы донести свою мысль разработчику.

Я про вашу фразу в 9-м посте: "Если вы не программист полноценного ТЗ вы не напишите". Это в корне не верно.

Неужели вы никогда не сталкивались с заказчиками, которые нахватавшись терминов (при этом совсем не понимая где и каким образом ЭТО нужно и можно применять) пытаются "облегчить" задачу? В итоге, после изрядно потраченного времени (и нервов) оказывается что им совсем не то надо было. (У меня это почти постоянно - все почему-то думают, что понимают в связи (я кроме всего прочего АТС-ки ставлю).)

neolord об этом сказал

Так вот ТЗ, по-моему мнению, пишут программисты или, если говорить в общем, технические специалисты, а то что пишет заказчик - это бриф. О чём я говорил в фразе "Если вы не программист полноценного ТЗ вы не напишите".

Убедили. 🍻 Хотя во многом зависит от сложности проекта и наличия\отсутствия тех. деталей.

Например бриф (или ТЗ?) которое может быть составлено заказчиком на программу:

Цель: создание программы "часы".
Функции и внешний вид:
1. Программа должна показывать текущее время и дату компьютера.
2. Возможность настраивать краткие и полные даты
3. Программа должна занимать на экране столько места, сколько необходимо для выводы времени и даты.
4. Возможность перемещения по экрану и установку в любом месте.
5. Возможность установки "Поверх всех окон"
6. Настройка цветов времени, даты и подложки программы по отдельности.
7. Настройка шрифтов времени и даты (как размера так и наименований).
8. Настройки должны вызываться по правому клику мыши и по комбинации клавиш.

Как видите, нет ни одного "программерского" термина.

(конечно, это "ТЗ" писалось сейчас, по чужому готовому продукту, но вроде как ничего не упустил ;))

В результате, может получиться например вот:

Скажете не описаны настройки (функционал\интерфейс)? Кроме того, есть некоторые неоднозначности (шрифты, например. Неясно - по-отдельности или общие для всего).

А это заказчику не важно. И отдаётся на откуп разработчику.

ЗЫ. Реальная программка несколько функциональней описанного ТЗ.

Вот выдержка из госта "ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ"

Думаю, вопросы отпадают, чем является ваш пример - ТЗ или брифом :)

p.s. Ваш пример я бы даже сказал, скорее ближе к user case - то есть к тому, с чем сталкивается в своей работе пользователь.

p.p.s. Тьфу, user story, а не user case :)