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 <bill@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.
>
>