Функциональные и нефункциональные инженерные требования

http://www.software-engineering-book.com/web/viewpoints/
через переговоры. Как правило, заинтересованные стороны должны встречаться для разрешения споров и согласования требований о компромиссе.

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

На рис. 4.7 показано, что идентификация и анализ требований — это итеративный процесс, включающий непрерывную обратную связь от одного действия к другому. Цикл процесса начинается с определения требований и заканчивается их документированием. Понимание аналитиком требований улучшается на каждом этапе цикла. Как только документ с требованиями сформирован, цикл завершается.
Будет полезно систематизировать и сгруппировать данные о заинтересованных сторонах, чтобы упростить анализ требований. Один из способов сделать это — посмотреть на каждую группу заинтересованных сторон как на точку зрения и собрать все требования этой группы с этой точки зрения. Вы также можете вводить представления из других систем, чтобы выразить требования и ограничения домена. В качестве альтернативы вы можете использовать модель системной архитектуры для определения подсистем и связывания требований с каждой подсистемой.
Неизбежно, разные заинтересованные стороны ­имеют разные взгляды на важность и приоритет требований, и иногда эти взгляды противоречат друг другу. Если некоторые заинтересованные стороны считают, что их мнение не было должным образом учтено, они могут намеренно попытаться сорвать процесс RE. Поэтому важно организовывать регулярные встречи заинтересованных сторон. Заинтересованные стороны должны иметь возможность выражать свои опасения и идти на компромисс по претензиям.
важно использовать простой язык и диаграммы для описания требований . ­Это позволит заинтересованным сторонам понять и интерпретировать эти требования . Лучше всего использовать общий документ (например, в Google Docs или Office 365) или вики, которую могут использовать все заинтересованные стороны для облегчения обмена данными.
Выявление требований включает в себя встречи с различными заинтересованными сторонами, чтобы узнать о предлагаемой системе. Вы можете дополнить эту информацию знаниями о существующих системах и их использовании, а также информацией из различных документов ­. Вам нужно потратить время, чтобы понять, как люди работают, что они производят, как они используют другие системы и как им нужно измениться, чтобы адаптироваться к новой системе.
Существует два основных подхода к определению требований:

1. 
   Интервью, здесь вы говорите с людьми о том, что вы делаете.
   
2. 
   Наблюдение или этнография, когда вы наблюдаете за людьми, выполняющими свою работу, чтобы увидеть, какие артефакты они используют, как они их используют и так далее.
   

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