Первое ТЗ , укажите пожалуйста на ошибки\недочёты

Написал первое ТЗ для программиста, подскажите пожалуйста, что подправить, что непонятного есть, лишнее и т.д?

Цитата

Написать класс представления личных сообщений (например class ls{ … }) :
Название методов\свойств\переменных на выбор

- Конструктор принимает 1 параметр – название таблицы MySQL (юникод, MyISAM), где находятся данные – структура (набросок, название полей и их типы, на усмотрение разработчика, указанные поля обязательные, но их можно дополнять, например на выбор добавив поле deleted – сообщение удалено, но не стёрто из БД и т.д.):
* id – ключ, автоинкремент (10, INT)
* user_form – id юзера, от кого пришло сообщение (10, INT)
* user_to – id юзера, кому пришло сообщение (10, INT)
* title – тайтл сообщения (255, VARCHAR)
* content – текст сообщения (TEXT)
* attach – прикреплённые данные (255, VARCHAR)
* timestamp – время передачи сообщения (16, INT)
* read – прочитано ли сообщение (1, INT, DEFAULT 0)
Для обращения к БД используется библиотека mysql (не mysqli), подключения не требуется, оно происходит в другом классе по умолчанию.

------------------------------------------------------------------------------------------

- Метод: function getMessages($count = 10, $page = 0, $read = NULL){ … }
Описание: Возвращает массив принятых сообщений
$count – количество возвращаемых сообщений
$page – страница сообщений (0 – возвращаются от 1, до 10 (если $count == 10), 1 – от 11 до 20 и т.д.)
$read - принимает 3 значения: NULL – возвращаются все сообщения, 1 – только прочитанные, 0 – не прочитанные
Возвращается ассоциативный массив: $arr[НОМЕР_СООБЩЕНИЯ][ЯЧЕЙКА_ДАННЫХ];
Пример возвращаемого значения:
$arr = $ls -> getMessages();
echo $arr[0][‘content’];
Возвращает текст первого сообщения.

------------------------------------------------------------------------------------------

- Метод: function getMessagesCount($read = NULL){ … }
Описание: Возвращает количество принятых сообщений
$read - принимает 3 значения: NULL – возвращаются все сообщения, 1 – только прочитанные, 0 – не прочитанные

------------------------------------------------------------------------------------------

Методы: function sendMessages и sendMessagesCount – синонимы getMessages и getMessagesCount, за исключением того, что возвращаются отправленные сообщения

------------------------------------------------------------------------------------------

Метод: function add($to_user, $title = NULL, $content, $attach = NULL){ … }
Описание: Добавляет сообщение в БД
$to_user – кому отправляется сообщение
$title - тайтл сообщения (не обязательный параметр)
$content – текст сообщения
$attach – прикреплённое к сообщению

------------------------------------------------------------------------------------------

Метод: function remove($id){ … }
Описание: Удаляет сообщение с выбранным id (не забыть проверить, принадлежит ли сообщение пользователю, который удаляет его)

------------------------------------------------------------------------------------------

Дополнительная информация:
Id текущего пользователя - $this -> core -> login -> user -> id; (класс в будущем будет наследовать другой, который имеет уже свойтсво\объект $core).

Методы __get(), __set(), __call(), если будут использоваться, должны иметь тип final для «перегрузки» наследуемых «волшебных» методов из наследуемого (извиняюсь за тафтологию) класса.

Встроенные PHP классы должны иметь глобальное пространство имён, например: \Exception или \DirectoryIterator и т.д. (но это мало должно волновать, потому что вряд ли будут использоваься)

Язык: PHP 5.3 (разрешается использовать безымянные функции\лямбда\замыкания и прочие няшки, запрещено использовние ereg регулярок (хотя здесь они и не пригодятся))

Доступ к БД можно производить через mysql_query, mysql_fetch_assoc и так далее.

Спасибо огромное

Сообщение отредактировано: Serafim - 09.03.11, 14:04

Можно добавить цену и срок

цену и срок как раз не надо было

Офигеть конечно. зачем так вдаваться в подробности...

У меня все просто:

Вот тебе дизайн, вот тебе то что оно должно делать.
Еб#$cь как хочешь, говнокодь, не говнокодь, но сделай.

Добавлено 10.03.11, 15:07
Поэтому я часто ощущаю себя говнокодером.

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

Ну тогда не легче это сделать самому?

легче но у меня дел и так полно помимо этого

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

согласен но за это время я успел сделать класс связи "друзей" и "стену"))

Это - вообще не ТЗ. Это функциональная спецификация класса, причем, пока - неполная.

CheshireCat, а что надо было написать тогда?

Зависит от того, что именно ты хочешь написать - ТЗ или спецификацию?

1. Если ТЗ:
Структура, состав и оформление ТЗ регламентируются ГОСТ 19.201-78 или аналогичными ГОСТ'ами 34 или 15-й групп. Насколько формально необходимо следовать этим стандартам в твоем конкретном случае - решать тебе.
В ТЗ (обычно) должны быть указаны:
а). назначение и область применения программы (или модуля),
б). функциональные требования,
в). нефункциональные требования,
г). порядок разработки, стадии и этапы разработки,
д). требования к документированию, включая пользовательскую документацию,
е). состав отчетных материалов, предоставляемых разработчиком по окончании работы,
ж). порядок контроля и приемки этапов и работы в целом.
Как минимум, должны быть пункты б (ну, функциональные требования ты описал), в, е, ж (а вот эти пункты отсутствуют полностью).
Т.е., разработчик должен после прочтения ТЗ понимать:
- как должна работать программа,
- в каком окружении она будет работать, с какими ограничениями может столкнуться,
- что он должен представить по окончании работы,
- как будут оценивать и принимать его работу.
Ну и как ты собираешься принимать работу? Ась?

2. Если функциональную спецификацию:
К ФС твой документ ближе всего. И тем не менее, мне после прочтения остались неясны следующие моменты:
а). общее описание и основное назначение модуля? (здесь достаточно написать 2-3 фразы, раскрывающие "контекст" - чтобы разработчику не нужно было додумывать и фантазировать. Он может нафантазировать такоооого!)
б). каковы принятые при проектировании описанного интерфейса модуля допущения и зависимости? какой код будет вызывать/использовать модуль, в каких условиях?
в). какие еще есть ограничения в архитектуре и дизайне, которые необходимо учесть разработчику? (по этому пункту кое-что указано, является ли этот список исчерпывающим?)
г). какие входные данные считаются допустимыми, но некорректными? какие - вообще недопустимыми?
д). каково должно быть поведение функций модуля при некорректных или недопустимых данных?
е). каковы возможные нештатные ситуации (исключения) и какова реакция модуля на них?
ж). есть ли и какова тестовая задача?
Отмечу, что, в соответствии с ГОСТ'ом, перечислить и описать возможные отказы разрабатываемой системы - это задача Заказчика. А вот реализовать грамотную реакцию на отказ - задача Исполнителя.