I've been working for the past few weeks on several features of this web site that I felt were important:

• The capability to aggregate RSS data from partner blogs and provide it on various views
• The capability to provide visibility of content which is still under development when desired
• The capability to subscribe to content and get email notification when it has changed

Such statements can form the start of functional requirements, but for me on this site, as in so many other situations, it's often first more fruitful to explore what's possible through prototyping and experimentation, before spending too much time trying to get the lower-level requirements right. This is particularly the case when the technologies you choose to use are unfamilar, evolving, or immature. In the case of the above capabilities, some required support from other open-source authors, some required changes on my web site host, and some were able to be done locally. 

However, in parallel with that exploration, there are additional considerations that I (as the web site 'owner') feel are important:

• Content which is extracted from other sites should be easily distinguishable from native content
• Content which is still under development should be easily distinguishable from released content

I consider these a special kind of requirement - policies. A policy is a business rule that is intended to drive behavior throughout an organization. It is similar to a regulation, though internally imposed. Like requirements, it defines the 'what', not the 'how' - but has to be deployed through the architecture of the organization so that the organization operates in a way that satisfies that policy.

When you run a business, you can make such policies, but without the mechanisms to make them happen - training, procedures, and tools - they may not be implementable within any kind of meaningful timeframe. Just like with the writing of requirements, it's best to do some prototyping and analysis, before you start issuing directives - otherwise, people may have no choice but to ignore them, a behavior you don't want to enforce. Similarly, you'll never know how good your requirements (or policies) are until you show them to the people that have to implement them, and ask them what they think they mean. 

Note that the policies I've provided above as examples are not directly implementable ('easily distinguishable' begs questions like by who? how easily?), but the intent can be determined. From that, a variety of people can then interpret that intent in many different contexts, decide what the gaps are, and make adjustments where necessary. With policies, you aren't usually just affecting one thing - that's why policy changes should be carefully evaluated and thoughtfully considered and planned.

As an example, in an earlier career, I worked in a surgical research laboratory. Back then, there wasn't a lot of attention given to careful disposal of needles or scalpel blades after they were used. There was risk inherent in that, certainly, but I frequently saw such items carelessly disposed of in waste baskets (even though there were separate disposal boxes for these 'sharps'). The individuals that disposed of the trash were aware of that risk, and were appropriately cautious; in the event they made a mistake, they were injured, and thus were reminded to be more careful.

However, as the AIDs epidemic began, the medical community had a much higher sensitivity to the handling of such equipment, and the commensurate risks involved, as their potential personal consequences of those risks increased. Suddenly, those boxes weren't just pushed to the corner. The boxes were easily accessible, everyone watched videos emphasizing why they were important, people talked openly about the risks and changes involved, and an accountability system was implemented. The policy was always the same, but the mechanics had to change.

Since the mechanisms often lag the policy, it's not enough to just issue the policy. There has to be a designated champion and consistent effort to drive the necessary changes, and ensure such changes are achieving the results that are needed. I have to do something like that on this site, with the issue tracking system I've prototyped. My vision for the business process that such a system should support is documented here. There are plenty of world-class tracking systems (commercial and open-source) out there already (for example, Bugzilla) - why would I want to build another? Actually, those reasons come back to my own personal policies about how I want this site to evolve:

• I want to use such issue tracking to demonstrate the linkage and integration of information needed to manage a project
• I want to demonstrate over time how a repository of such information can prove useful for purposes other than just burning down problems
• I want it to be aligned with my vision
• I want it to serve as a means of evaluating workflow capabilities and group-level access features within Drupal, so that selected visibility of information is provided based upon who you are, and where you are in a workflow
• I want that information to be based upon functionality on my site, rather than across other web services
• I want to control my own destiny

In practice, it's not my intention to provide all of the functionality of these other systems, but only enough to satisfy the above objective.

There are tens of thousands of such tracking systems out there, and they all offer lots of functionality - but someone has to tailor and implement that functionality to a particular set of policies and requirements, and then roll that out to a user community. For example, just because you're using a tracking tool in your own group (even a world-class one), the issue tracking processes and tool setup may not provide for:

• concurrent issue management of multiple projects
• sharing of data across sites or companies
• coordinated planning of components concurrently used by multiple projects
• analysis of root causes for problems
• tracking how much time is actually spent working on a problem
• predicting cycle times and backlog of problem resolution

Each of those introduces challenges (from both a process and tool perspective). More importantly, the community doing that work may not be motivated to implement such changes, unless they understand the importance of those changes - the 'sharps' in the garbage. That's why both policies and mechanisms are required.