В этой статье я решил в общем виде рассмотреть такой этап разработки ПО, как составление требований. Несмотря на то, что большинство программистов пренебрегают этим этапом в своей работе, тот, кто научится выполнять этот этап самостоятельно – перейдет на совершенно новый уровень разработки ПО.

Что же такого классного в этом, я расскажу далее.

Для начала можно перечислить все абстрактные преимущества выполнения этого этапа:

1. У программиста появляется больше уверенности в процессе кодирования.
2. Процесс выполнения проекта становится легче отслеживать.
3. В любое время можно примерно оценить время, оставшееся до конца разработки.

Для менеджеров IT проектов эти вещи, конечно же, являются скорее необходимостью, чем преимуществом, но ведь ими еще надо стать И эта статья будет Вашим первым шагом на этом пути.

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

Именно для решения этой проблемы, со временем, составление требований к ПО выделилось в отдельный этап.

Теперь представим, что перед нами стоит задача написать небольшую систему для управления небольшим предприятием Тут понятно, что начинать надо с определения того, что система должна делать… С чего бы Вы начали составлять требования?

Иногда требования классифицируют на функциональные и нефункциональные. В нефункциональных требованиях отображают требования к системе исходя из того, в какой среде она будет работать. Например, аппаратное обеспечение, на котором будет работать программа, время отклика системы (быстрота реакции на действия пользователя), сторонние приложения которые будут использованы программой, или ресурсные ограничения (использовать не больше 10Мб памяти, например).

Что касается функциональных требований, то в них как раз описывается то, что должна делать программа. Функциональные требования в первом приближении обычно пишут на естественном языке. Например, на первом этапе можно просто сформулировать общую задачу, для решения которой наша система предназначена. Для ERP это будет выглядеть так:

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

Этот абзац представляет собой отправную точку всей работы и обычно фигурирует при заключении контракта между предприятием и компанией-разработчиком ПО.

Далее пишется более детальное описание всего функционала на… можно и на естественном языке Но прежде чем приступить к подробному обзору этой темы Вам необходимо самим попробывать составить свое первое требование к программе. Это необходимо для того, чтобы Вы столкнулись со всеми трудностями этого процесса, а в одном из следующих постов я расскажу что бы уже придумано для их разрешения

Удачи.