From: Bill Wishon <bill@wishon.org>
To: emacs-orgmode@gnu.org
Subject: Org-mode for Product Requirements
Date: Mon, 16 Apr 2012 17:39:19 -0700 [thread overview]
Message-ID: <CAP2uJAtOczOGAxTYL7xEfbe6b2e8VTi2rgM5djemOTavs19U2Q@mail.gmail.com> (raw)
[-- 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 --]
next reply other threads:[~2012-04-17 0:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 0:39 Bill Wishon [this message]
2012-04-20 23:46 ` Org-mode for Product Requirements Bill Wishon
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=CAP2uJAtOczOGAxTYL7xEfbe6b2e8VTi2rgM5djemOTavs19U2Q@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).