OSS Requirement Capture

Whatever pursuit you undertake, the requirements should start with a love of what it is that you are pursuing.”
Bill Toomey.

Every OSS project starts with a set of requirements. They’re used to describe what you want to achieve after the project is delivered.

We’ve tried four different approaches, with each suiting different project / client types. These approaches are:

  1. The traditional requirement capture approach
  2. An alternate approach is to capture the required benefits.
  3. The Persona / User-story approach
  4. The Multi-Filter Approach.

Let’s take a closer look at each of these approaches and provide some examples.

1.1 OSS Requirement Capture by Features

The traditional requirement capture approach was to capture a set of functional (and non-functional) requirements that the solution needed to fulfill. This could be useful when there are many stakeholders who have very detailed needs (refer to the Trashing Technique). These can sometimes be very detailed and risk over-specifying the outcome. However, it’s also a useful technique if you have very specific needs and have the appetite (and resources) to build / customise a solution to meet them all. However, this technique is less useful if you have tight budgetary constraints and need to find a pragmatic solution of best-fit.

The following template can be used to assist you to capture the requirements of your OSS and prioritise the most important functions / benefits.

It can also be incorporated into the first step of our vendor selection process, assisting to create a short-list of potential products / vendors that most suit your needs.

OSS Requirement Capture Template (sample only)

As you’ll notice, there are 16 sections of requirements, but only the first part of the first section (NMS Hardware and Software) is shown in the attachment.

If required, this requirement capture template can be modified to align with TMF’s The Application Framework (TAM).

1.2 OSS Requirement Capture by Benefits

An alternate approach is to capture the required benefits. This approach tends to be less prescriptive and allows more flexibility by implementation teams. This requires trust in the project team that’s building the solution. To complement this trusting approach, it’s also recommended to use a process of iterative development, allowing the client / users to steer the solution.

!! Template coming soon !!

1.3 OSS Requirement Capture by User Stories

The Persona / User-story approach comes from a more Design Thinking perspective. This approach is gaining increasing popularity and aggregates the required outcomes from the perspective of each persona / user (or user group) as well as the activities they perform

The persona / user-story technique is more nascent (see here for a definition of User Stories). I’ve found it to be very helpful to quickly capture the intended outcomes of a couple of recent OSS tools I’ve been working on.

This Sample User Story Template has been cropped so as to not give too much away about this new product, but it does give an indication of how the template functions.

The columns are described in more detail as follows:

  • Story Number – a unique number to differentiate between stories
  • Role – who needs this scenario
  • Action – what the scenario is
  • Benefit – why the scenario is important
  • User Story – is a compilation of “As a <role> I want to <action> so that <benefit>” The template has an auto-formula that calculates this sentence from the data in columns B, C and D
  • Priority – allows developers to quickly identify which story to develop next
  • Estimate (hrs) – estimates the number of hours required to develop each story
  • Confirmations (tests) – itemises high-level test cases for the test team to build their test cases around
  • Module – this is only used if your solution consists of multiple separate modules and allows quick identification of which stories align with which modules

1.4 OSS Product / Vendor Selection using Filters (aka The Multi-Filter Approach)

The outcome of this technique is not so much about building a list of requirements, but taking a step back and asking why you even need a requirements list. If you need a list of requirements primarily as a method for identifying a product/s of best fit, then this technique will help you achieve this but without a lengthy list of requirements. The attraction of this technique is that it quickly identifies the solution that best suits the client needs. This technique is fast and efficient (great for clients with budget and/or time limitations), but might not be detailed enough for some clients (especially clients with high risk aversion or appetite for customisation).

You can find a more detailed description of the multi-filter approach in this article.

Summary

If you’d like the full version of any of these templates (or assistance in customising your own templates), please contact us here.
If you find any of these templates helpful, I’d love to hear about your story, your project and any other enhancements that you’ve made to the template.