Sharing requirements with git for transmedia applications

In my previous post about the topic I wrote about the abstract requirements of transmedia applications. When talking about transmedia applications I think of many independent code bases serving the same business values on different platforms. They share the programming language independent features like the branding, and the purpose they intended to deliver. The native iOS and Android Facebook applications unlikely reuse any code from each other, yet most of Facebook's features can be accessed without having to learn a new interface.


Let's say we got involved with building news portal. The publisher decided to create web application, a PC application and several other apps for Android, iOS and WinPhone. Dealing with so many different teams and technologies it does not seem trivial to keep the acceptance criteria of features in sync between each working group. It might feel even harder if the development of each application happens in different times, and time zones. For example when the work on the desktop application begins in Moscow 3 months after the web app team has started their work in San Francisco, would the original requirements still stand? Did the work on the web app alter the original values? Does the team in Moscow know about the changes if there are any?

How does the git multiverse look like for our news portal?

We have a separate repository for feature files describing the core business requirements which each application must deliver. In addition to that, we have repositories for each platform to hold the platform related requirements. The feature repos are set up to only handle files ending in *.feature to avoid noise and confusion when someone is using them. To make this happen, the .gitignore file needs the following entries:

*.*

!README

!*.feature

!*.gitignore

view raw .gitignore This Gist brought to you by GitHub.

We have repositories for each application. These contain the given application's code, configuration, tests and resources. The software can be built, deployed and shipped from its own isolated repository without having any impact on the others. The individual applications become linked only by using git submodules to attach the higher level features onto their own local scenarios. This means that whenever someone changes a requirement in the platform or the core level, it becomes available for each leaf of the repository tree.

/app
  |-source
  |-tests
  |-features
     |-local
     |-platform (submodule)
     |-business (submodule)

A simple CI process can react upon a commit to one of the feature repositories, and verify that the application could still handle the changes. If so, it can bump the linked version of the requirements of the given app. If not, it can signal that some work is needed. This however does not work well if the changes are pushed down as they happen. We should keep in mind that core level modifications might have a huge ripple effect, and they need special atention. The benefit of using git submodules over svn:externals for example lies in the fact that the development teams can decide when to pull in the changes.

This model can help products to share vision and identity through the interfaces it has. Keeping a consistent behaviour and user experience might have a higher impact on reliability and market acceptance than anything else.

The application is not the product. The application only acts as an interface to the product.

My next post in this series will describe how to write application agnostic requirements, and how to think about them on the other end of the wire.