Requirements have a long history in software industry. We all have heard or read terms like: requirements definition, requirements management, requirements decomposition... tons of books, trainings and requirements themselves have been created for software all over the world.
Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.
Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.
In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably miss the factors that influence the way requirements are defined. There is no way to avoid this it is true no matter how knowledgeable and experienced requiremens author(s) are. Conversely, by refraining oneself from going too far with definition, the authors get a chance of opening their minds to factors that help them discover that which they have possibly never conceived otherwise.
Factors that help us discover requirements:
from users or stakeholders seeing
the thing on demos, tradeshows, etc. This may be unfinished, unreleased work shown to existing or potential users, people funding the work and other stakeholders. They get a chance of influencing the direction for the product or its features before they will get to use it.
from users using
the thing. This may be partial, staged roll-out of a bigger feature, provding basic functionality and then iteratively enhanced using that feedback. Check out the Walking Skeleton, if you have not done already. This feedback can be gathered directly or we can try to encourage the users to fill in surveys (good luck!) or use Google Analytics to discover behaviors and patterns.
Ideas from Sprint reviews.
Sprint reviews are fantastic opportunity to look together at was done, exchange opinions and decide on the next steps for the feature. A good review may sometime trigger nice additions to what is being developed, but it can also result in the decision to change the direction more strongly, or to abandon something previously defined or developed.
such as the contents of data being processed or displayed, existing code, existing UI/UX design or technical limitations can also fuel requirements discovery. This relies on the ability of requirements author to engage into a technical discussion with the team and their willingness to listen and take that kind of input into account. Yes, I mean it - if being a PO (or similar role) you developed the thinking that you can get away with just "defining The What" with no interest in The How, don't hope for big successes with the team.
Aim of consistency
Similarly, aim of purpose
can remind us the intent for our product. Even as the feature set grows, the "one tool for everything" approach never pays off in the long run.
And last but not least, the Proof of Concept
(or Spike) activity can shed light on what we can or cannot do and strongly influece the requirements at an initial stage.
To sum it up, we should open our heads to factors described above, and any other that we can spot in our work. We need to accept the fact that we are not able to do a good "definition" job sitting at the desk and staring at computer screen. Instead, go discover what's waiting out there. Then work on the definition for a while and then go discover again. This is how great features emerge.