We really should visualise requirements
A random idea for interactive requirements modelling.
I am a big fan of visualising complexity to enable holistic view of a domain, illustrate hierarchy, relationships and dependencies, check for completeness, facilitate clustering, prioritisation and roadmapping.
But I have yet to find a tool that allows me to do this with requirements: traditionally we manage requirements in lists (spreadsheets or backlogs) or kind-of-visualised form (scrum or kanban boards). However, I have yet to find a tool that allows visual modelling of requirement hierarchy and relationships.
These are some random thoughts on how such a solution could look like.
Rationale
As part of valuable solution scoping and planning it is important to view requirements in the context of their hierarchical relationship to solution slices and features (and each other, i.e. dependencies) rather than just in prioritised isolation.
Traditionally requirements are managed in flat requirements documents or management software which represent requirements as text and organise them generally speaking against top level categories (e.g. epics-stories) or priorities (e.g. backlog). This does only provide limited context and makes it hard to consider requirements holistically and illustrate size, scale and complexity of a project. The available interactive tools for requirements management work generally against lists, boards or storymaps, rather than allowing more flexible visual representation of requirements to, for instance express, relationships, categorisations or affinities.
Solution outline
A distributed, access-controlled, cross-device solution that allows management and representation of requirements (here synonymously used with epic or story) as nodes of a network diagram and allows these nodes to be visually manipulated (name, position, formatting, relationships).
Principles
the system allows for any number of hierarchical levels, representing anything from products to feature groups, top or detail level requirements (epics, stories, etc).
the primarily supports a hierarchy tree, i.e. a 1:n parent-node to child-node relationship. (This is important to enable compatibility with requirements tracking solutions such as JIRA which work in simple relationships.)
the system will allow to model additional relationships such as dependencies and n:n relationships between child and parent nodes
Supported key use-cases
create new node and define level of hierarchy applicable to this node
define / edit node name
define node priority and assign related
position node (drag&drop)
format node appearance (to mach hierarchy level, priority or individual nodes)
create primary relationship to parent node
create secondary relationship(s) to other nodes
format relationship to highlight relationship type
delete node
Indicate work status of node
auto-positioning of nodes to create ideally-spaced tree/network
import requirements from other requirements management solutions (e.g. JIRA) and represent in solution. Note: this should be possible by taking the requirements number as primary key and matching — or creating where required — nodes accordingly. Hierarchy and relationships will be reflected as in requirements management solution.
Any additional visualisation specific information (nodes not in requirements management solution, formatting, positioning, relationships) will be maintained in visualisation solutions database and matched via the requirements ID (primary key).export requirements from solution for import into requirements management solutions
export in tabular format (xls / cvs)
represent requirements in tabular format to facilitate fast entry of requirements in text-based way
additional use cases related to creation / deletion / management of multiple projects, users and roles
A quick note before we start: I am a big fan of agile software delivery. And somehow I can’t shake the nagging feeling that visualising requirements (stories if you like) goes a bit against agile paradigms (should we ever have so many requirements that they need visualisation in the first place?
On the other hand, delivering agile doesn’t mean that we won’t have to model a more complex domain at least initially to make sense. Anyway, I don’t have an answer for this yet, but still this tool may come in handy I feel anyway. And of course, if you are going down a more waterfall route replace story with requirement and such a tool will certainly come in handy.
