From: Bill Wishon <bill@wishon.org>
To: emacs-orgmode@gnu.org
Subject: Re: Org-mode for Product Requirements
Date: Fri, 20 Apr 2012 16:46:41 -0700 [thread overview]
Message-ID: <CAP2uJAsQx4aUvQx2hhVcpHkgb+n6=i9VJd_EFoSSbNusHJVvNA@mail.gmail.com> (raw)
In-Reply-To: <CAP2uJAtOczOGAxTYL7xEfbe6b2e8VTi2rgM5djemOTavs19U2Q@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2012-04-20 23:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 0:39 Org-mode for Product Requirements Bill Wishon
2012-04-20 23:46 ` Bill Wishon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAP2uJAsQx4aUvQx2hhVcpHkgb+n6=i9VJd_EFoSSbNusHJVvNA@mail.gmail.com' \
--to=bill@wishon.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).