Technology Transfer Requirements Engineering - On the Value of Conceptualizing Alternatives

by Blagovesta Kostova

What is this paper about?

It’s about my experience working in a startup. The story is just as many, a couple of people at a university had an idea to search on remotely-stored encrypted data without descrypting them and at some point someone told them “You might be able to sell this idea”.

Yes, it is possible to search on encrypted data but it is hard to go from a purely technical research idea and prototype to a sellable product/service. In startups there are many ideas, many dreams but little resources and even less certainty what it is that we do.

However, what we knew was that we had technical expertise in cryptography and we wanted to protect data without data users losing functionality.

TTRE: Meet-in-the-middle approach for business and technology

How do we go about designing business and technology together, when we’re talking about a strartup? What we came up with was TTRE, or technology transfer requirements engineering. TTRE is a process of 4 steps and 2 domains.

What we consider here is that the business and the technology domains influence each other and provide feedback and guidance on how to conduct the next steps of TTRE.

TTRE: Observe

Look at your code or a piece of technology and try answering the following questions: What can the code do? How does the code do it? What components can be extracted based on functionalities?

Now look around for your business domain and try finding it. Who is there to talk to? What needs do they have? Here, we can use traditional customer development and approach people with a clear slate mind but never ignore the technical idea that is in the background.

TTRE: Model

It’s time to model. Modeling your code provides with an explicit structure, it serves to document the architecture, and models can be used to communicate and negotiatie interfaces to customers.

By modeling the business domain, we place services, providers and adopters in the same model and document explicitly our hypothesis of what the business value is for our customers. We’ll put this hypothesis to the text in the next steps.

TTRE: Construct

Of course, we need to build a prototype and answer an important question: is it technologically feasible what we’re trying to do. Here we’re in the research realm, not everything has been invented yet.

At the same time, on the business side, we communicate requirements, this is not a waterfall developement afterall, and we benefit from co-development and potential higher buy-in from our future customers.

TTRE: Contextualize

This is where we apply our solution and answer the most important questions: is is usable and is it sellable? Hopefully, our prototype is both at the same time.

Back to the future

The main findings from TTRE are a couple. First, every service that we conceptualize requires a different value network that the startup has to create and also, every services requires a different marketing and sales strategy. THis does not allow the startup to explore too many different services at the same time. Second, layering services and connecting them explicitly enables us to design custimizable instead of customized software. The refinement of the service systems and nesting of the different services within each other places potential customers on a map, and where there is a map, there is a direction.

Concluding remarks

This paper is built around my experience in one startup but I have seen that the other startups struggle as well with designing their software product while at the same time trying to find what business they are in. The data in the case is limited to one case but I’m in the process of first, refining TTRE and then testing it in a different setting.