Quick update, Here's a start at the type of org doc I'm aiming to build ultimately with the help of my new org-prd module : http://dl.dropbox.com/u/25725498/org-prd.org It's actually the first draft of the PRD for org-prd.
And here's my start at the org-prd.el itself. It's a small start with only a function to create a unique CUSTOM_ID, but it's a start as I get familiar with elisp and org-mode hacking. http://dl.dropbox.com/u/25725498/org-prd.el ~>Bill On Mon, Apr 16, 2012 at 5:39 PM, Bill Wishon <b...@wishon.org> wrote: > Hi Org-mode Community, > > I'm a product manager and I've been using org-mode for quite some time and > was recently thinking how Org-mode might be a good starting point for a > personal product requirements management system. I've searched around a > bit and didn't find any discussions about such a topic, and before I start > down this path I figured I'd send a note to this group to: > a) See if anyone else uses org-mode for product requirements. I'd like to > hear about that. > b) Get feedback on my approach from other org-mode users. How I'm > thinking of using properties, tags, TODO state, hooks, etc... > > I thought Org-mode would be a good place to start since, for me > requirements are a bit like TODO items, I come across them during meetings > with colleagues and customers and want to track them inline to the context > that I find them in. I then want to take these "requirement" todo items > and add a bit of structure and collect them in a different document. > > I'm leaning toward using a "requirement" tag on my TODO items since > semantically the item is still a todo item, and the tag indicates a special > way to handle that todo. I suppose the other way would be to create a new > TODO state like REQ. Any reason why one would be better than the other? > > I'd probably start by hooking into org-after-todo-state-change-hook and > looking for DONE and the requirement tag. And if I'm completing a TODO > requirement then : > 1. Choose the destination, maybe try and leverage existing "refiling" > logic. > 2. Copy the headline into the requirements document leaving behind the > original completed headline and a link to the new requirement location. > 3. Generate a file unique CUSTOM_ID like REQ-005 if this was the fifth > requirement. This would allow for creating relationships between > requirements without regard to their names. > 4. Create the mandatory properties, perhaps this is just some type of > template text for now, maybe a series of "wizard like" questions in the > future. > > Then I'd also create a custom export option. Two things come to mind here > in addition to what I already know about customizing html output. > i. Formatting the properties in a specific order and in a custom way, > emphasizing some properties over others. > ii. How to get links in properties to work during html export like they do > if you put a link in a text body. eg: in emacs [[#REQ-001]] displays as a > link whether it's in a property or text body, but when exported as HTML > only the one in the body text is an html link, the link in the property is > just the original literal text [[#REQ-001]]. > > In the future I can see doing the following sorts of things: > * Generating different views (both in emacs and for export) eg: roadmap > view, filter by release, dependency tree view > * Computing statistics like the number of requirements per release, amount > of estimated engineering effort per release, etc... > * Validate requirements checking for entries missing required properties, > or entries that don't state something firm eg: has the words must or shall > > I'm only just beginning on this and I'd appreciate any feedback and advice > the group may have. > > Best, > ~>Bill > > Here's a sample of what I'm thinking in org mode format: > * Introduction > * Use Cases > * Features > ** Standard File Dialogs > :PROPERTIES: > :CUSTOM_ID: FEAT-001 > :Topic: File IO > :SolvedBy: [[#REQ-001]] [[#REQ-002]] > :END: > The product shall have standard file Open, Save, Save As features > * Requirements > :PROPERTIES: > :Status_ALL: new reviewed approved assigned "in development" complete > :END: > ** Save as > :PROPERTIES: > :CUSTOM_ID: REQ-001 > :Topic: File IO > :Status: assigned > :Release: Astraeus > :Created: [2012-04-16 Mon] > :Author: Bill Wishon > :SolvedBy: [[#REQ-002]] > :END: > The product shall allow for users to save things to a different name. > ** Save > :PROPERTIES: > :CUSTOM_ID: REQ-002 > :Topic: File IO > :DependsOn: [[#REQ-001]] > :END: > The product shall allow for users to save their work. > >
