Requirements Management for Continuous Software Product Development

Background: Continuous software product development is increasingly becoming the norm. New requirements come in a constant stream and need to be assigned to projects to make it into a release. However, in the literature requirements management practices are project based and no longer naturally fit to this new setting. Aim: Thus, it is of interest to understand the industrial practices for the identification of requirements and associated artifacts put under configuration control. Method: An industrial survey with five companies was conducted to find out these industrial practices. Results: The results of this survey show that with the need to manage more requirements also comes the need for greater control. Large companies, however, often place similar control on products of all size. Moreover, regardless of size and requirements management practices, companies face the same problems. Conclusions: All companies should keep requirements associated material under some form of control and updates to them should be communicated to the involved stakeholders and should be easy to access. The type of associated artifacts kept under control can be decided by the criteria given.


INTRODUCTION
Best practices for requirements management (RM) were written when software was mainly developed in bespoke projects (Leon, 2005).However, current industry practices are moving towards the continuous development of software products.This involves a constant stream of requirementsforcing large numbers of requirements on product managers.
The change in development practices brought about by continuous software product development (CSPD) means that RM must be undertaken at a higher level, where requirements are assigned to projects and releases of the software to maximize the economic benefits of the software development process.
While, RM literature provides no guidelines for working with this new approach to software development, this situation is currently being managed in industry.To understand current approaches used in industry this paper presents an industrial survey of the practices used for the identification of artifacts relating to requirements that should be put under configuration control (CC).
Section 2 introduces the key concepts and the research questions.Section 3 contains results of the industrial survey.The threats to the validity of survey results are presented in Section 4. The results are discussed in Section 5 with the conclusions.Future work is presented in Section 6.

BACKGROUND
The need for managing changes in requirements is well acknowledged (Sommerville and Sawyer, 1999) and is required by a number of quality models, such as CMMI (CMMI-SE/SW/IPPD/SS, 2001).RE activities for CSPD are considered 1) critical to the success of the enterprise and 2) have many interfaces in form of multiple internal and external stakeholders (Wohlin and Aybuke, 2005) and both these criteria suggest the resultant artifacts should be placed under CC (Leon, 2005).In this context potential items that can be placed under CC can range from individual requirements belonging to different decision stages of CSPD (such as candidate, approved and planned requirements) to requirements associated artifacts (such as business context, business analysis, product strategies, feasibility analysis, value descriptions describing the value a certain requirement adds to a product, requirements decisions and motivations and grounds for these decisions) (Fogelström et al., 2008, Gawdiak et al., 2006).
Selecting which items should be placed under CC and selecting techniques that are appropriate for managing controlled items is one of the most important tasks within SCM (Leon, 2005).Placing too much under CC will unnecessarily increase costs and placing too little under CC will result in increased costs due to information loss and wasted effort.
While there is much information on RM practices for requirements already assigned to a project (Sommerville andSawyer, 1999, Leon, 2005) Decisions taken on a particular feature (vi) Decision's rationale To find out the level of granularity, RQ2 aims to identify the techniques/approaches used for keeping track of each item under CC.The possible techniques can range from no CM to more formal change control through change control board (CCB).RQ3 aims to investigate the criteria commonly used for identification of items which need to be tracked and managed.RQ4 and RQ5 are targeted to find out the current challenges and benefits faced/realized related to CC of requirements and associated artifacts.
To address these research questions, an online survey was developed (http://www.surveymonkey.com/s.aspx?sm=ZZ_2fPmdunYSPHIBvQqSwtbw_3d_3d).Companies within our industrial collaboration network were invited to participate, with invitations sent to professionals involved with receiving, approving, tracking/maintaining, doing feasibility analysis of, and performing initial screening of features.

RESULTS
In total 12 people responded to the survey, two providing responses for two products.An overview of the companies and products surveyed is in Table 1.All five companies target customers globally.The companies range in size from medium (50-250 employees) to large (> 5000 employees).For reasons of confidentiality companies are anonymous.
The responses for RQ1 show all companies track candidate, approved and planned requirements, and feature decisions.This is done either formally or informally.Requirements associated artifacts and decisions rationale, are kept under control by only company Athe largest company.Addressing RQ2, the results show the two largest companies (A and B), with the greatest number of candidate requirements for all of their products, have controls ranging from tracking of these requirements through to a change control board (CCB).However, the remaining three companies (C, D and E) have no change control and change management for the candidate requirements.
For approved and planned requirements, the larger companies (A and B) use a formal CCB for approval and changes.In the smaller companies updates to these requirements are informalmeaning anyone can make changes, but involved stakeholders are informed of the changes.Only Company A claims to have a high level of control over requirements associated artifacts for approved and planned requirements with CCB being responsible for these items.The other companies did not see this as applicable to their context and do not have CC in place for these items.
For some products (A1, A2, B1, D1) feature decisions are kept under formal controls and update procedures.An informal process is reported for changes/updates in feature decisions for E1.The remaining products either have no CC mechanism (A3) or decisions are not tracked (C1).For decision rationale only products with a greatest number of approved and planned requirements (A1, A2, and B1) have controls in place with a CCB.Other products have no change management or it is not applicable in their context to track and control decision rationale.
In answering RQ3, the most common criteria used for deciding which items to track were items that are considered critical for business and items that are used/affected by different parties in the analysis and refinement of requirements.This was indicated by companies A, C and D. Additionally, sub-contractor involvement is also a factor for more formalized control.Company D also reported that it is important to track complexity of requirements and the associated costs as they are sources of potential risks.
The most important challenges in relation to CC of requirements and associated artifacts, addressing RQ4: (i) Updates to the requirements or associated artifacts are not communicated to important stakeholders (ii) The effect of adding or removing a requirement from release scope is not clear (iii) Difficulty in effectively managing changes in the priority lists and release scopes Issues related to version control (e.g.different stakeholders keep different versions of requirements priority lists for the same release) were considered as less important.This is noteworthy as most CM tools focus on version handling.
Addressing RQ5, the greatest benefits, of tracking and managing requirements and associated artifacts: (i) Better communication and handling of changes in the requirements priority lists and release scope (ii) Faster and better informed decisions: Information can be easily traced and retrieved The least important of the benefits studied was the possibility to follow up decisions and improve.

Conclusion Validity
The sampling techniques used for identifying the respondents can pose a threat to the validity of the survey results.The subjects selected may not be totally representative of the roles involved in requirements management.The main assurance that this misrepresentation is minimal is the fact that the subjects were selected in cooperation with an experienced person in each company who had extensive knowledge and experience about the roles and responsibilities of the subjects.

Internal Validity
As the answers to the survey questions were registered along with the subjects' personal information this could have constrained subjects in their answers.This potential problem was alleviated by the guarantee of anonymity as to all survey answers, and that answers were only to be used by the researchers, i.e. not showed or used by any other party.

External Validity
The external validity is concerned with the ability to generalize the results.The survey was limited in scope as there were only 12 respondents from five companies; therefore the results are not generalizable.However, this survey was a first study of its kind to identify RM practices in the context of CSPD.The results have provided some insight into current RM practices which will be used as an input for an extensive survey with a large sample.

DISCUSSION AND CONCLUSION
The results show products with a large number of requirements are put under stricter control, and larger companies need more control than smaller ones.However, it can be seen that larger companies have more control even for products with fewer requirements as RM practices are standardized across a company.This can make large companies less capable of acting swiftly with small products.
It is interesting that the most important issue faced in tracking and management of requirements and associated artifacts is updates to the requirements or associated materials are not communicated to important stakeholders.For medium sized companies this is explained by the fact that different types of requirements and their associated artifacts are either controlled informally or are not kept under CC.However, for the larger companies, which reported to have formal CC procedures for requirements and associated material, this might be an indication that information on what to control and how to control is present, but the information is not easily accessible.
The second challenge reported has probably risen due to the fact that none of the companies chose items having many interfaces with other software/product items as a criterion to choose the items to be put under CC.This means that the dependencies between requirements are not kept under CC, explaining the difficulty of estimating the affect of adding or removing a requirement to/from a release scope.The difficulty in effectively managing changes in the priority list and release scopes could be due to the fact that medium sized companies informally control updates to the approved and planned requirements and the associated artifacts.This indicates a need for a formal tracking of inter-dependencies between approved and planned requirements and management of associated decision and decision rationale to enable effective RM.
No company reported the possibility to follow up decision and improve.Under time-to-market pressures, the companies probably have not been able to realize the of looking at earlier decisions.It could also be that the decisions are not stored in a usable format and since it requires an effort to examine and use these decisions, they are possibly not utilized from the perspective of long-term improvement.Thus, whether requirements associated artifacts and decision rationale are stored or not, companies are losing the opportunity to benefit from key lessons and corporate knowledge, which are very important for strategic planning in CSPD (Gawdiak et al., 2006).From the results and discussion, lessons learnt are:  Large companies should have lighter version of CC for smaller products in order to ensure efficient handling of requirements. All companies should keep requirements associated material under some form of control and updates to them should be communicated to the involved stakeholders and should be easy to access.The type of associated artifacts kept under control can be decided by the criteria given. In order to perform impact analysis of adding/removing a requirement to/from a release scope, requirements interdependencies need to be kept under CC.

FUTURE WORK
This paper presented results of survey conducted to identify RM practices in CSPD context.The sample size was small, thus as a next step we plan to replicate the survey with a large sample population to 1) confirm the results and 2) to identify other trends which were not identified in this survey.
Another direction for future work is to study in depth the interesting findings identified through the survey responses.For example, why companies are not using past decision rationale to enable effective and efficient decision making?Understanding these issues at a deeper level will allow best practices to be identified, helping companies improve their RM practices.

Table 1 :
Overview of the survey respondents