Software Requirements In Startup Companies

Published Date: 02 Nov 2017

1. Introduction

Two days after my graduation I find myself in a plane to San Francisco to start an unpaid internship at a startup called Fair Observer, an online media platform with over 300 contributors in 30 countries. Fair Observer was solely financed by the founders, their families and friends, and money was running low because of high expenses then low income. If we could not find an investor by December 2012, our web hoster would pull the plugs to our servers. The team had high pressure of generating income and at the same time meet the expectations of potential investors. We realised from early on the necessity to provide a significantly higher user value compared to existing solutions, to successfully position the product of our new venture. Achieving significant higher user value is the outcome of innovation, the heart of most startups, and accompanied with increased creative thinking during the requirements process. At the day of my arrival, I was shown wireframes of a new mobile application that I was supposed to start developing that day. The team was fast. Driven by the fear to stomp, what we believed to be change the world, into the ground, mockups and wireframes were developed at the speed of light and were ready to be developed. Not soaked in yet by the pressure of time and money, I foolishly asked one essential question: "Why? Why have we chosen a mobile strategy? Why do we have to develop a new platform in the first place? What was needed to achieve our goals? What are our goals?" Not only were requirements not documented to efficiently transfer knowledge to new team members like me, but requirements were not defined at all. No one could clearly explain why we did what we did.

The Startup Environment

My story is far from unique. Although all businesses have to cope with the similar challenges, certain issues tend to be presented in software startups to an extreme degree. Characteristics that are widely representative for software startup companies lie within business and engineering concerns. A software startup is not defined by its size – it can consist of either a small or large development team – but by its youth and immaturity (Sutton, 2000). Startups act under high uncertainty and spend most of their time searching to validate requirements and market needs. They tend to have a young and inexperienced character with limited operating history, limited resources, time-to-market pressure and operate in dynamic technologies and markets (Sutton, 2000; Zettel et al., 2001; Loch et al., 2008). External capital is usually raised over several rounds of financing to cover their expenses. To secure the next rounds of financing, software developers tend to concentrate on short-term achievements, instead of following a long-term orientation (Zettel et al., 2001). At the same time, startups try to reduce the number of financing rounds by generating earnings as soon as possible to reduce the dependence on other parties.

The pressure of time-to-market, inexperience and interactions with venture capitalists is likely to have implications on the software development. This claim was also expressed by several researchers (Lindvall & Rus, 2000; Sutton, 2000; Fayad & Ward, 2000). The characteristics of a startup lead to a unique environment associated with positive attributes like agile, innovative and creative, as well as negative ones like immature and hasty. This results in opportunities as well as risks such as the opportunity to bring software faster to the market than larger companies and the risk to develop software that is not of value. However, the risk of a product that does not meet the needs of the users and the business will prevent the start-up from maturing.

Current Literature

Startups were often associated with agile software methodologies (e.g. Sharp & Robinson, 2004). Agile methods were not intended to replace traditional methodologies, but create a symbiotic relationship, dependent on the application domain and innovativeness (Cohen et al., 2004). Agile methodologies intend to have continuous control of the software requirements and continuously validate them. They aim to provide maximum flexibility regarding changing requirements and focuses on a better understanding of what the user needs are. Agile software development consists of various methodologies, of which Extreme Programming, Scrum and Crystal are the most well-known. Looking at the discussion of development processes, it is surprising to see that the organisation type plays a small role in the software engineering literature (e.g. Dybå & Dingsøyr, 2008). Abrahamsson et al. (2003) conclude in their comparative analysis that agile methodologies were found to be effective and suitable for many situations and environments but guidance is needed on how the methods should be used in certain software development situations. "Empirical works that study the effects of particular (agile) methods, their ease of use, costs, and possible negative implications for different sizes and lines of business, are needed in particular." (Abrahamsson et al., 2003, p. 252)

Zettel et al. (2001) claim that startup companies do not make use of established software methodologies by book and the used practices are immature and ad-hoc, as well as implemented by accident. Own observations support this statement. Sharp & Robinson (2004) conducted an ethnographic study of Extreme Programming (XP) practices in a startup to characterise the XP culture. They were "struck" by the lack of requirements documents, but concluded that XP showed to be useful in their case (Sharp & Robinson, 2004; p. 373). Academic research is otherwise scarce, since most work lacks empirical support and is based on the experiences of practitioners or consultants. One such publication is Eric Ries’ New York Times best seller "The Lean Startup" (2011). Ries knows to sell the lean software methodologies by Poppendieck & Poppendieck (2003) with unassailable marketing expertise to startup companies. His claims on the effectiveness of such approaches are based on anecdotal evidence and not empirical research. The Lean Startup Movement and personal experiences and observations indicate a strong need for proper guidance on the handling of requirements in startups.

2. Method

A literature review will be conducted, making use of the proposed guidelines for systematic reviews for software engineering researchers by Kitchenham (2004).

2.1 Research Questions

The research question will be refined after the literature review, from the following:

Q1: How do startup companies elicit, analyse, specify and manage software requirements?

Q2: Do the practices match known software engineering methodologies or principles?

Q3: Is the introduction based on an adoption by book or by accident?

Q4: What are the challenges when dealing with software requirements in startup companies?

Q5: How useful are agile software methodologies for handling requirements in startup companies?

Q6: What implications have venture capital investors on the requirements?

2.2 Research Method

The research method consists of a survey and a case study. Requirement practices will be studied in an online questionnaire on a sample of software startups. The data will be used to draw conclusions on the software requirements and software development in startup companies (Q1 – Q3). A survey was chosen to do a first research in the large and help identify subjects for the case study. 

The empirical research methodology by Petersen (2010), which evaluated the usefulness of agile practices in a large-scale industrial setting, will be adapted. Startups will be studied in real life situation due to the practicality of software engineering. A multiple-case study will investigate requirements in software startups in-depth. The case study is of confirmative nature and will enable to draw conclusions on software requirements in startup companies (Q1-Q6). The study design is fixed and agreed on with the startup companies and involved investors. The analysis of case studies ranges from a purely qualitative analysis where raw data from interviewees is categorised and coded to the exclusive use of statistical inference. The motivation to choose case studies as a research method was implied by the objective to investigate software requirements in startups in a real-world setting. It will not be insightful to replicate the environment in an experiment, or obtain similar qualitative data in a simulation. Action research is a suitable alternative, but relies on the willingness of the startups to change their processes and is associated with greater efforts. Semi-structured interviews and workshops will be used as sub-methods for data collection.

Participants will reflect and give feedback on the usefulness of the methodologies for handling requirements and challenges in working with them. Sources for quantitative data will include closed company data and data from internal reporting tools of the business incubators under provision of quality checks to assure validity.

2.3 Measures

The online questionnaire will collect data on team size, level of agile experience, level of development experience, project duration and domain, as well as questions directed at the way they develop software requirements at the present.

Qualitative variables of the case study include: 

Structure, plan and control of the development process.

Stakeholders influence on the selection of software development methodologies.

Characteristics of requirements elicitation, analysis, specification and management.

Perception of bottlenecks, unnecessary work, avoidable rework for the requirements. 

Feedback from practitioners on approaches they believe to be useful.

Ability of the approaches to support practitioners to elicit, analyse, define and manage software requirements.

Ability of the approaches to show presence of inefficiencies or opportunities. 

Investors' influence on software requirements.

2.4 Participants

Inclusion factors for the survey (N=100) include a limited operating history, a scalable or repeatable business model and software development as a key activity. Participating startups will be based in Silicon Valley (USA), London and Oxford (UK) and Munich and Berlin (Germany). These three locations were chosen due to their known importance and influence for entrepreneurial thinking and innovation. Nine startups will participate in the case studies and will be selected using the data obtained in the survey, based on their representativeness for the population.

The importance of access to startups that are willing to participate is recognised and the risk minimized by the use of established connections to startup companies and startup programs. Personal relations to contact persons in the following places were established through my attendance at workshops, conferences, competitions and employment:

Plug and Play Tech Center: global accelerator (Silicon Valley)

Birmingham Science Park Aston (UK)

Oxygen: accelerator (UK)

Entrepreneurs for the Future: incubator and accelerator (UK)

Central Working: incubator (UK)

Entrepreneur First: incubator (UK)

F6S: startup community (UK)

Oxford Entrepreneurs: student society (UK)

Cambridge University Entrepreneurs: student society (UK)

Entrepreneurship Center of the Ludwig Maximilian University of Munich: incubator (Germany)

Strascheg Center for Entrepreneurship: incubator (Germany)

Social Entrepreneurship Akademie: incubator (Germany)

Thinc!: student initiative for entrepreneurs by the University of Mannheim (Germany)

Vodafone Stiftung Deutschland: supporting of social businesses (Germany)

BonVenture: supporting social entrepreneurs (Germany)

Faculty of Organizational Sciences by the University of Belgrade: incubator (Serbia)

StartupWeekend: startup competition by the Kauffman Foundation (international)

2.5 Data analysis

Standard statistical packages (R) will be used to visualise quantitative data, perform correlation analysis and regression to establish relationships. For the qualitative data, a qualitative data analysis software package will be used to assist coding and visualise relationships from the interview and workshop data. The concepts of grounded theory and statistical analysis will also be applied to reduce data through coding, visualise data and document relationships in mind-maps to aid the analysis.

2.6 Outcomes

The intended final outcomes of the research will be:

Understanding of requirements in startups.

Empirical evidence of the usefulness of identified software methodologies in a software startup setting to develop requirements.

Proposal of guidelines for startups to adopt software methodologies that support requirements elicitation, analysis, specification and management.

3. Significance

Startup companies are a major striving factor of the economy’s growth (Autio et al., 2012). Researchers in economics sciences realised that startups are not a smaller version of larger companies and that existing processes cannot simply applied to startups. There is a great need to adopt the software methodologies that are being in use to the special environment of a startup and little is still known about their elicitation, analysis, specification and management of requirements. Since startups are more likely to fail from a lack of customers than from a failure of product development, it is essential to find suitable approaches to develop requirements effectively. Guidance for software startups will be beneficial, due to their lack of time and money for designing their own development processes.

The outcomes of this study could also be applied to other organisational forms that intend to become more agile. It is further hoped that the research will establish an innovative model to study implications of innovation, creativity, immaturity and speed-to-market in a development process. These characteristics are present to an extreme degree in startups, which offers the opportunity for concentrated research. Speaking of an example, the creativity and innovation in startups is most likely resulting in ethical conflicts that need to be handled faster then usual due to the speed-to-market.

4. Preparation

The unique environment of startups was experienced first hand when working for a startup in Silicon Valley, an incubator at the University of Munich, participating in international startup competitions and recently co-founding a startup where I lead the software development. The observations lead to personal research on the inefficiency of the applied methodologies and realisation of the importance of requirements in startups.

I am aware of my lack of knowledge, in particular in the field of Requirements Engineering. I was therefore starting to work on a research project on creativity in requirements engineering under supervision of Dr. Rami Bahsoon and Dr. Leticia Duboc at the University of Birmingham recently. The project is planned to being expanded in my MSc dissertation and gives me the opportunity to study requirements and will provide me with deep understanding about requirements engineering and practical experience researching these empirically.

5. Proposed development

Phase One:

Comprehensive literature review according to Abrahamsson (2003) to help refine the research questions and research methodology.

Rethinking the nature of the methodologies and consider the possibility to conduct action research to better observe the effects of the introduction and implementation of the methodologies.

Continuation and expansion of relations to business incubators, accelerators and individual software startups.

Entering dialogue with researchers and practitioners in the field of agile software development, software requirements and entrepreneurship.

End of phase one:

Conducting and analysing the survey.

Writing of the progress report and refining the research plans for phase two.

Phase Two:

Fixing the study design the participating startups agree on.

Conducting the case studies according to the research plan.

Analysing the data according to the research plan.

Writing of the progress report and refining the research plans for phase three.

Phase Three:

Finishing the data analysis.

Conducting a supplementary literature review.

Interviewing the startups on their long-term perception and recent events.

Writing up of the dissertation.

6. Conclusion

Empirical research on software engineering in startup companies is still scarce although their unique characteristics are likely to have implications on the process. Empirical evidence on the usefulness of software development methodologies and guidance for startups on the implementation those is needed.