The phenomenon known as ‘Living Apart Together’ (LAT) marks a new form of commitment. Living apart is hard and the base for good LAT-relationships are clear agreements, commitment and common understanding.

Similarly, ‘Working Apart Together’ (WAT) requires clear agreements, dedication, and a mutual understanding. Communication, however, is hard work. To align the FundRequest team members, we rely on a light-weight Functional Analysis to drive the development efforts.

We’re not talking about heavy project related documentation such as BRS or PID documents. That’s overhead we just don’t need in a start-up world. We’re talking about solid functional analysis as the baseline for clear communication

But which analysis models to use exactly?

At FundRequest we use a limited set of models and stick to these as the baseline for discussion:

Business Process Models (BPM): show how the business should work by sequencing the flow in a series of steps. They are easy to read and are used in the communication with the business stakeholders and the users’ community.

Use case diagrams: provide a view on the sequence of interactions between the user (in different roles) and the system/sub–systems. In fact, the use cases define how the business processes can be realised by the system or the different components of the system.

Domain Model (logical data model): structures the information into meaningful real-world concepts that needs to be developed in software. The concepts include the data involved in the business, and the rules the business uses in relation to that data.

A light-weight Functional Analysis supported the WAT-development of our Alpha

The FundRequest Team is typically a team which is Working Apart Together. At least once a week, we come together physically to sync, but the rest of the week, we are all working remotely using collaborative working tools like Slack, Google Documents, Google Hangouts, GitHub, …

Our Working Apart Together relationship is driven by a light-weight set of functional models.

Please checkout our alpha at https://alpha.fundrequest.io/ to see the product which is developed based upon the following analysis. More detailed information can be found in the documentation page of our Alpha Release.

Business Process Models

It all starts with discussions from the business’ and user’s perspective. In our alpha, we want to showcase the funding and rewarding of open source development using blockchain. More specifically, using our alpha it will be possible to fund a GitHub issue using FND-tokens, and claim the reward of that GitHub issue when a solution has been pushed to GitHub.

Fund a FundRequestIssue (linked to a GitHub-Issue)

Claim reward from a solved FundRequestIssue (linked to a solved GitHub-Issue)

Use Case Diagram

Once the BPM’s are stable, we decide which system (component) will be responsible to achieve the goal of the different business processes. This leads to the Use Case Diagram Model. Please be aware that the Use Case Diagram Model only gives an overview of which subsystem is going to realise which use case. The real functionality and added-value is elaborated in the description of the use cases.

From the Use Case Model, we further refine to the Product Backlog, and together with the developers, the team then decides upon the priorities in which order the Product Backlog is going to be implemented.

Domain Model

Finally, the most important model to drive the development germinates from the previous steps where the business processes and the use cases are described. In fact, there is a continuous interaction between the elaboration of the Domain Model, and the concepts and business rules which are described in the business processes and the use cases.