From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Wishon Subject: Org-mode for Product Requirements Date: Mon, 16 Apr 2012 17:39:19 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec554df8e5ca41e04bdd52b7b Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SJwS6-0008Ga-KQ for emacs-orgmode@gnu.org; Mon, 16 Apr 2012 20:39:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SJwS4-0004BR-9O for emacs-orgmode@gnu.org; Mon, 16 Apr 2012 20:39:26 -0400 Received: from mail-lpp01m010-f41.google.com ([209.85.215.41]:49386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SJwS3-00048w-UO for emacs-orgmode@gnu.org; Mon, 16 Apr 2012 20:39:24 -0400 Received: by lagz14 with SMTP id z14so4935179lag.0 for ; Mon, 16 Apr 2012 17:39:20 -0700 (PDT) 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 --bcaec554df8e5ca41e04bdd52b7b Content-Type: text/plain; charset=ISO-8859-1 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. --bcaec554df8e5ca41e04bdd52b7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.

--bcaec554df8e5ca41e04bdd52b7b--