Пользовательские истории - это, вероятно, наиболее широко распространенная техника в плане требований в мире Agile. Этот скромный шаблон «кто-что-почему» изначально был создан командой Connextra в Лондоне и быстро получил широкое распространение:

Не думаю, что когда-либо буду собирать требования по проекту или планировать релизы ПО каким-нибудь другим способом. Всякий раз, как я упоминаю «сбор требований», профессионалы IT представляют себе перспективу написания доисторического документа в Word. За долгие годы IT-индустрия была завалена всевозможными шаблонами требований и документами в Word. Подписание технического задания было сопряжено со всевозможными тревогами: все ли требования идеально изложены, согласованы с бизнесом, а впоследствии реализованы? А что будет, если требования изменятся? Ох, батюшки… Надо бы завести себе контроль изменений и список согласований!

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

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

В последнее время все больше людей интересуют методологией гибкой разработки ПО (agile). Многие люди или работают в такой среде, или хотели бы попробовать. Кто-то думает в стиле гибкой разработки, кто-то считает себя гибким. Гибкость - это то, что ценят люди при взаимодействии с процессами и инструментами. Но во многих «гибких» ситуациях люди все же хотят работать по набору правил, заданных стандартным фреймворком. Самый популярный такой фреймворк на данный момент - это Scrum.