From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Wishon Subject: Re: Org-mode for Product Requirements Date: Fri, 20 Apr 2012 16:46:41 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec553ffc074970704be24e6f3 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:58523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SLNXL-000157-1T for emacs-orgmode@gnu.org; Fri, 20 Apr 2012 19:46:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SLNXI-0004jJ-9L for emacs-orgmode@gnu.org; Fri, 20 Apr 2012 19:46:46 -0400 Received: from mail-lb0-f169.google.com ([209.85.217.169]:43213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SLNXH-0004ih-Ss for emacs-orgmode@gnu.org; Fri, 20 Apr 2012 19:46:44 -0400 Received: by lbbgg6 with SMTP id gg6so2301623lbb.0 for ; Fri, 20 Apr 2012 16:46:41 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --bcaec553ffc074970704be24e6f3 Content-Type: text/plain; charset=ISO-8859-1 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 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. > > --bcaec553ffc074970704be24e6f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Quick update,

Here's a start at the type of org doc I'm aimi= ng to build ultimately with the help of my new org-prd module : http://dl.dropbox.com/u/25725= 498/org-prd.org=A0 It's actually the first draft of the PRD for org= -prd.

And here's my start at the org-prd.el itself.=A0 It's a small s= tart with only a function to create a unique CUSTOM_ID, but it's a star= t as I get familiar with elisp and org-mode hacking.=A0 http://dl.dropbox.com/u/25725498/org-p= rd.el

~>Bill

On Mon, Apr 16, 2012 at 5:3= 9 PM, Bill Wishon <= bill@wishon.org> wrote:
Hi Org-mode Community,

I'm a product manager and I've been u= sing org-mode for quite some time and was recently thinking how Org-mode mi= ght be a good starting point for a personal product requirements management= system.=A0 I've searched around a bit and didn't find any discussi= ons 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.=A0 I'd li= ke to hear about that.
b) Get feedback on my approach from other org-mod= e users.=A0 How I'm thinking of using properties, tags, TODO state, hoo= ks, etc...

I thought Org-mode would be a good place to start since, for me require= ments are a bit like TODO items, I come across them during meetings with co= lleagues and customers and want to track them inline to the context that I = find them in.=A0 I then want to take these "requirement" todo ite= ms and add a bit of structure and collect them in a different document.

I'm leaning toward using a "requirement" tag on my TODO i= tems since semantically the item is still a todo item, and the tag indicate= s a special way to handle that todo.=A0 I suppose the other way would be to= create a new TODO state like REQ.=A0 Any reason why one would be better th= an the other?

I'd probably start by hooking into org-after-todo-state-change-hook= and looking for DONE and the requirement tag.=A0 And if I'm completing= a TODO requirement then :
1. Choose the destination, maybe try and leve= rage existing "refiling" logic.
2. Copy the headline into the requirements document leaving behind the orig= inal completed headline and a link to the new requirement location.
3. G= enerate a file unique CUSTOM_ID like REQ-005 if this was the fifth requirem= ent.=A0 This would allow for creating relationships between requirements wi= thout regard to their names.
4. Create the mandatory properties, perhaps this is just some type of templ= ate text for now, maybe a series of "wizard like" questions in th= e future.

Then I'd also create a custom export option.=A0 Two th= ings 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, empha= sizing some properties over others.
ii. How to get links in properties t= o work during html export like they do if you put a link in a text body.=A0= eg: in emacs [[#REQ-001]] displays as a link whether it's in a propert= y 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:
* Gener= ating different views (both in emacs and for export) eg: roadmap view, filt= er by release, dependency tree view
* Computing statistics like the numb= er of requirements per release, amount of estimated engineering effort per = release, etc...
* Validate requirements checking for entries missing required properties, o= r entries that don't state something firm eg: has the words must or sha= ll

I'm only just beginning on this and I'd appreciate any fe= edback 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
** St= andard File Dialogs
:PROPERTIES:
:CUSTOM_ID: FEAT-001
:Topic: File= IO
:SolvedBy: [[#REQ-001]] [[#REQ-002]]
:END:
The product shall have sta= ndard file Open, Save, Save As features
* Requirements
:PROPERTIES::Status_ALL: new reviewed approved assigned "in development" co= mplete
: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
:Depen= dsOn: [[#REQ-001]]
:END:
The product shall allow for users to save th= eir work.


--bcaec553ffc074970704be24e6f3--