Nowadays, due to the advance of the technology and easy access to information, almost anybody has the opportunity to build virtually any software product or service and address it to the global market. Despite its relatively short history, the software industry has flourished attracting a huge interest and effort into developing, testing, marketing, and selling its products, amongst many other related activities.
The Requirements Engineering (RE) [1,2] is a crucial part of the software development process. It has been proven, both in the literature [3,4,5] and from our experience in ISDC, that functional misunderstandings or inaccurate business activity models imply far smaller costs when discovered during the requirements development or the grooming stages than when their effects appear after the software goes into production. Moreover, the largest chunk of a software development budget is absorbed by the maintenance costs which are tightly influenced by the quality of the initial requirements. The Product Owner (PO) is one of the stakeholders that use the RE community and their process for describing, documenting and eventually building the product. For a PO, the end users are the customers and the RE is one of the tools used to satisfy the customers" needs. By changing the reference coordinate system, the RE process can also be seen as the product that the software companies, through their REs, are offering to the corporate stakeholders which, consequently, become customers.
The Lean methodology was first used by Toyota in their production system. It is focused on producing only the features valued by the customer, thus, increasing quality and reducing development time and costs. In his book, The Lean Startup, Eric Ries [6] defined the startups as "a human institution designed to deliver a new product or service under conditions of extreme uncertainty." Therefore, startups imply human interaction in a structured way. In the Requirements Process developed at ISDC, this approach is similar to the requirements elicitation and gathering. For these steps, our RE community uses various well defined investigation techniques, such as interviews, workshops, observation, prototyping etc. in order to extract customer needs. Moreover, the second part of the definition points out that a startup delivers a product or service without knowing exactly how it will suit the needs of the end users. Again, this is very similar to the service offered by our REs that has to develop a set of requirements [7,8,9] that will have to fit the needs of our customers while describing the product as accurately as possible. Starting from the observation that the RE department in a software company is similar to a startup organization, we will analyze the idea of extrapolating the Lean principles developed for startups.
The objective of this paper is two-fold: first, we aim to present in a new light the traditional RE process and warp it as a product that the RE department is "selling" to the project"s stakeholders; second, we would like to investigate how the Lean methodology can be applied to the RE activity. Interestingly enough, the Lean methodology can be simultaneously applied to both parties involved in the RE activity: the customer for defining the actions that the startup has to take in order to build a successful product, and the RE community for defining the actions that have to take in order to satisfy the customer"s needs and obtain a software product with the desired functionality.
Software products can be developed using different methodologies such as waterfall, iterative or agile. Independently of the chosen approach, the RE is a mandatory step that precedes any development activity. Usually, in our company the requirements phase is followed by the development and finally by the release of the product. Thus, the learning phase of one of our customers launching a novel product is divided between the requirements stage and the release, with a higher share after the release, when the market acceptation can be measured.
Figure 1 depicts a typical production flow that starts at the requirements stage followed by the actual development and quality assurance and concludes by the release.
During the first stage, we must go through a learning process while adapting our customer"s requirements to the activity field and technical constraints. However, at the beginning, there are very few clues about how the product will impact the end users and how they will receive and understand it. When the developed products include an important innovative component it is very difficult to predict the feedback they will receive once on the market. Whilst the next two stages after the RE focus on the actual development process, the highest amount of learning will be harvested after the product is launched.
The Lean methodology reverses the traditional industrial production process formed by the "Build, Measure, and Learn" sequence. Instead, the Lean theory defends the idea of creating a Minimum Viable Product which is used for learning what the customers really want and, subsequently, being able to adapt the product in order to suit the real needs of the customers, as illustrated in Figure 2.
Focusing on the RE stage and continuing with the analogy between the RE community and a startup, the ISDC RE community tried to understand how to apply the lean methodology by defining the main blocks of the internal RE process. Traditionally, the RE process comprises the following major steps: planning, elicitation and analysis, development, requirements management, requirements communication and auditing. As shown in Figure 3, this process follows the Build, Measure and Learn flow.
In order to adapt to the Lean requirements process, the RE should develop the requirements in small iterations and validate the results continuously with the customer. The development of the requirements must be a priority as it brings valuable knowledge to the REs both in terms of the functionality of the product and regarding the way of working of the customer and their expectations for the results of the requirements development process.
Applying the Lean methodology, this means that this process should be reversed by trying to learn as much as possible and as early as possible in the RE process. As Steve Jobs said, "it"s not your customer"s job to know what they want", thus the RE must be able to obtain the correct information by creating a Minimum Value Requirements Product (MVRP) and measuring the customer"s feedback. Trying to identify a concept and then validating it through empirical experiments is also known in the Lean methodology as "Validated Learning". From our experience, the lack of validated learning leads to frustrations on both sides and delays in the product development.
When analyzing and building a startup, the Lean canvas offered by Lean Stack [10] is a valuable tool both. Therefore, the Lean canvas can also be used by the RE community.
Considering the Product and the Market, as the two main concerns of a startup, the following issues must be taken into consideration:
• Market
One of the most important steps when building a startup is to clearly identify the customer. In the ISDC RE process, this is equivalent to identifying the stakeholders accountable for the product development. In order to identify the right persons, the analysis must consider the appropriate number of candidates. It shouldn"t include too many stakeholders because this will lead to non-manageable set of rules. On the other hand, the group must not be too narrow as the target segment diminish and the input from important customers can be missed.
Once the list of stakeholders is clearly formed, the stronger customer segment must be identified. This includes the customers that have some kind of connection with the REs, for instance, that are easier to reach or that can communicate better. At this point is very important to distinguish between customers and users. The rule to apply is that customers pay while the users don"t. The group of early adopters is formed by people that need the product the most. This group is crucial for collecting feedback even before starting to build the product and identify the most valued features.
As in any startup, the RE community in ISDC is able to identify the problem to solve for the customer. As a lesson learned from our projects, a good approach is to identify the top 3 problems of the customers using the five whys root cause analysis. It is also very interesting to write down the solutions that the customer is using to overcome these problems and identify his possible alternatives for improving the current situation. The product or the service that the RE is offering doesn"t have to be perfect but must be clearly better than all the existing alternatives. For instance, we use to bring in external domain experts as part of the RE community. This can bring in a fresh and better view compared to what the customer would get by using internal business analysts that would most certainly be biased by the internal knowledge.
Another aspect to evaluate when defining a solution for the customer"s problems is to understand what the offered product is displacing. All products displace something and our sales and RE teams aim at building a clear case upon why the customer should take the risk of making that switch. We are always careful with this aspect because the services offered to our customers will probably replace the tasks of an already existing internal team or will disturb some established flows between the end users and the customer"s IT department.
The MVRP, meaning the solution implying the least development effort and offering value to the customer, must be defined. The solution may not be unique and the customer usually has several propositions, including the ones issued from our competitors. In order to attract the customer"s attention, we focus on defining a Unique Value Proposition (UVP). The UVP must be placed at the intersection of the main problem of the customer and the proposed solution. For a maximum impact, the UVP must be stated clearly and should include the result that will be provided to the customer, a specific time interval an address potential objections. For instance, a proposal that our REs presented to a customer sounded as "Clearly defined specifications in x working days with bugs free software guarantee". The unfair advantage or entry barrier represents a feature that can"t be easily copied or bought and can be used to enforce the UVP. It is also useful at this point to prepare a metaphor that gives the non-technical customers a clear image of the RE service effects or characteristics.
When necessary, the channels or paths to customers can be defined. Usually, starting with a few inbound or outbound channels can be very useful for learning.
Defining key metrics is essential for measuring the success of our projects. In order to build appropriate metrics, our RE community identifies what the customer perceives as value and uses it to define success. The fixed and variable costs are also evaluated against the metric for success in order to prioritize them.
This paper was focused on the RE service as it is offered by our company. In ISDC, we see it both as a product in itself and as an entrepreneurial activity. This vision lead to the idea of adapting the Lean principles to the RE in order to improve our overall process. The Lean methodology is focused on using activities that produce value for the customer while reducing the development cycle time, increasing the quality of the product and reducing the costs. One of the key concepts of Lean is the Minimum Viable Product which is the implementation implying the least development effort and offering value to the customer. We show that the requirements can also be shaped as Minimum Viable Requirements Product for our customers.
Other contributions of the Lean methodology to the ISDC requirements process are the concept of Validated Learning and the idea of reversing the traditional product building sequence and transforming it into Learn, Measure and Build. Developing requirements in small steps and validating the results with the customers is crucial. By doing so, the RE community accumulates valuable knowledge both in terms of the functionality of the product and the way of working of the customer and their expectations for the results of the requirements development process.
"Requirements Engineering in an Agile Environment", Yunyun Zhu, Department of Information Technology, Uppsala University, 2009
"Best Practices for Requirements Gathering", Michael Krasowski, Online course at http://pluralsight.com/
"Dependency based Process Model for Impact Analysis: A Requirement Engineering Perspective", Chetna Gupta, Yogesh Singh, Durg Singh Chauhan, International Journal of Computer Applications (0975 - 8887), Volume 6- No.6, September 2010.
"Impact Analysis of Goal-Oriented Requirements in Web Engineering", Jose Alfonso Aguilar, Irene Garrigos, Jose-Norberto Mazon, The 11th International Conference on Computational Science and Its Applications (ICCSA 2011).
"Requirements Engineering", Elizabeth Hull, Ken Jackson, Jeremy Dick, Springer, 5 oct. 2010.
"The Lean Startup: How Today"s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses", Eric Ries, Crown Business (September 13, 2011), ISBN-10: 0307887898, ISBN-13: 978-0307887894