Почему требования к системе необходимо документировать? Какие существуют способы документирования требований?

Требования обычно используются как средство коммуникации между различными заинтересованными лицами. Это означает, что требования должны быть просты и понятны для обычных пользователей и разработчиков. Один общий способ задокументировать требование — это написать утверждение о том, что должна сделать система.

В зарубежной и российской практике встречаются следующие типы документов требований:

-Концепция программы (Vision)

-Спецификация программного обеспечения (англ. Software Requirements Specification, SRS)

Спецификацию программного обеспечения часто называют техническим заданием. Это ошибка. Спецификация требований является частью технического задания в случае создания автоматизированных информационных систем.

За создание спецификации программного обеспечения чаще всего в российской практике отвечает Системный аналитик, иногда — Бизнес-аналитик.

Для графических моделей требований исторически использовались диаграммы или методологии графического моделирования: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

Взято с википедии, в лекциях нашел только очень расплывчатую инфу по этому вопросу.

В чем состоит суть понятия «процесс» при разработке ПО? Почему необходимо придерживаться в ходе разработки определенного процесса? Каковы функции процесса в разработке ПО? Какие процессы разработки ПО Вы знаете?

Процесс разработки программного обеспечения — структура, согласно которой построена разработка программного обеспечения (ПО).

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

Различие в понятиях(чтобы не путаться) со SWEBOK:

"Модели жизненного цикла задают высокоуровневое определение фаз (стадий) разработки программного обеспечения. Их целью не является предоставление детального определения, но концентрируется на ключевых работах и их взаимосвязях. Примерами таких моделей* являются водопадная (каскадная - waterfall), модель прототипирования, эволюционной разработки, инкрементальная/итеративная, спиральная и т.п." "Определения процессов жизненного цикла обычно являются более детальными, чем модели. Однако, определения процессов не описывают порядка их выполнения во времени (за это как раз и отвечают модели, прим. автора). Это означает, что, в принципе, процессы жизненного цикла программного обеспечения могут быть “выстроены” (во времени) соответственно любой модели жизненного цикла." "В рамках данных понятий жизненного цикла - “модель” и “процессы”, возможно говорить, что совокупность модели, процессов и практик определяет метод/методологию поддержки жизненного цикла."

Суть понятия процесса, да и то, зачем он нужен:

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

Примеры процессов:

-Водопадная(каскадная модель),

-Итеративный процесс

-Гибкие методологии(XP - экстремальное программирование),

-Спиральный процесс(Шаблоны(или методологии, хз): RUP, EUP, MSF for CMMI).