The requirements mindset

Requirements are a means to an end; a way to instill confidence in the user that you've understood him, his concerns, and what to do to resolve them. These become concrete triggers and handle bars to manage in a business IT environment.

A professional should be able to clearly communicate what to do, either for himself or towards others. Requirements are helpful in doing so, by providing a mindset of prioritization and categorization. Whether you're a functional analyst, a technical architect, a consultant, a manager, or a programmer, being able to do requirements well allows you to understand what you do. A particular role, a particular person might be better suited to establish a set of requirements (e.g. a business consultant and business requirements; an architect and system requirements) than another, but the understanding is necessary to identify gaps, and to be able to get requirements as a whole to a proper level of detail.

Requirements will change. The further along you get, the tougher and the more expensive those changes become. This is no excuse to have bad requirements or not pay attention to them. Having good requirements change allows you to mitigate risks, have a clear view of impact, and establish confidence, control and a framework for change to the user.

Requirements are never written in isolation. They must be agreed upon/signed-off, and better still, be co-authored with the user and the stakeholders. Also requirements can be well-written on their own, but still be bad when regarding all the requirements.