emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Org-mode for Product Requirements
@ 2012-04-17  0:39 Bill Wishon
  2012-04-20 23:46 ` Bill Wishon
  0 siblings, 1 reply; 2+ messages in thread
From: Bill Wishon @ 2012-04-17  0:39 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 4240 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Org-mode for Product Requirements
  2012-04-17  0:39 Org-mode for Product Requirements Bill Wishon
@ 2012-04-20 23:46 ` Bill Wishon
  0 siblings, 0 replies; 2+ messages in thread
From: Bill Wishon @ 2012-04-20 23:46 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 4614 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5196 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-04-20 23:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-17  0:39 Org-mode for Product Requirements Bill Wishon
2012-04-20 23:46 ` Bill Wishon

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).