Budget and schedule constraints limit the number of requirements that can be worked on for a software system and is thus necessary to select the most valuable requirements for implementation. However, selecting from a large number of requirements is a decision problem that requires negotiating with multiple stakeholders and satisficing their value propositions. In this paper I present a two-step value-based requirements prioritization approach based on TOPSIS, a decision analysis framework that tightly integrates decision theory with the process of requirements prioritization. In this two-step approach the software system is initially decomposed into high-level Minimal Marketable Features (MMFs) which the business stakeholders prioritize against business goals. Each individual MMF is further decomposed into low-level requirements/features that are primarily prioritized by the technical stakeholders. The priorities of the low-level requirements are influenced by the MMFs they belong to. This approach has been integrated into Winbook, a social-networking influenced collaborative requirements management framework and deployed for use by 10 real-client project teams for the Software Engineering project course at the University of Southern California in Fall 2012. This model allowed the clients and project teams to effectively gauge the importance of each MMF and low-level requirement and perform various sensitivity analyses and take value-informed decisions when selecting requirements for implementation.

Selecting system and software requirements to implement in a particular product or release is a challenging decision problem. Business stakeholders strive to maximize return on investment by selecting the most valuable requirements for implementation. Deciding on the requirements to be selected entails a great deal of communication and coordination amongst the stakeholders to ascertain the priorities of the individual requirements. The prioritized requirements aid in the planning and sequencing of implementation activities associated with the software system and provides a basis of a prioritized backlog from which the requirements can be ‘pulled’ for development. Changing business priorities may require a complete reprioritization of the backlog, leading to wasted effort. Individual change requests and new requirements need to be prioritized and inserted into the correct location in the backlog requiring high communication overhead. In this paper we summarize a two-step prioritization approach using a decision theoretic model to prioritize system and software requirements that alleviates these concerns. The system is initially decomposed into high-level Minimal Marketable Features (MMFs) and each MMF is further decomposed into low-level requirements. The MMFs are prioritized against the business goals of the organization and the low-level requirements with respect to ease of realization and business value. The priorities of the individual requirements are influenced by that of the MMFs they belong to. This two-step approach serves as an important prelude for a dynamically prioritizable product backlog. In this paper we present a proof-of-concept of having implemented this approach with 24 real-client student project teams at the Software Engineering project course at the University of Southern California.

As software evolves, the number of test-cases in the regression test suites continues to increase, requiring testers to prioritize their execution. Usually only a subset of the test cases is executed due to limited testing resources. This subset is often known to the developers who may try to “game” the system by committing insufficiently tested code for parts of the software that will not be tested. In this new ideas paper, we propose a novel approach for randomizing regression test scheduling, based on Stackelberg games for deployment of scarce resources. We apply this approach to randomizing test cases in such a way as to maximize the testers' expected payoff when executing the test cases. Our approach accounts for resource limitations (e.g., number of testers) and provides a probabilistic distribution for scheduling test cases. We provide an example application of our approach showcasing the idea of using Stackelberg games for randomized regression test scheduling.

Easy-to-use groupware for diverse stakeholder negotiation has been a continuing challenge [7, 8, 9]. USC's fifth-generation wiki-based win-win negotiation support tool [1] was not as successful in improving over the previous four generations [2] as hoped - it encountered problems with non-technical stakeholder usage. The popularity of Facebook and Gmail ushered in a new era of widely-used social networking capabilities that I have been using to develop and experiment with a new way for collaborative requirements elicitation and management - marrying the way people collaborate on Facebook and organize their emails on Gmail to come up with a social networking-like platform to help achieve better usage of the WinWin negotiation framework [4]. Initial usage results on 14 small projects involving non-technical stakeholders have shown profound implications on the way requirements are negotiated and used, through the system and software definition and development processes. Subsequently, Winbook has also been adopted as a part of a project to bridge requirements and architecting for a major US government organization.

Avoiding a major source of system and software project failures by finding more non-technical-user friendly methods of system definition and evolution has been a significant challenge. Five generations of the WinWin negotiation framework have improved such capabilities, but even the latest WikiWinWin toolset has encountered problems with non-technical stakeholder usage. With the advent of social networking and popularity of Facebook and Gmail, we have developed a radically different way for collaborative requirements management and negotiations. The new avatar of the WinWin framework called `Winbook' is based on the social networking paradigm, similar to Facebook and content organization using color coded labels, similar to Gmail. Initial usage results on 14 small projects involving non-technical stakeholders have shown profound implications on the way requirements are negotiated and used through the system and software definition and development processes. Winbook has also been adopted as part of a project to bridge requirements and architecting for a major US government organization.

There are usually more requirements than feasible in a given schedule. Thus, it's imperative to be able to choose the most valuable ones for implementation to ensure the delivery of a high value software system. There are myriad requirements prioritization frameworks and selecting the most appropriate one is a decision problem in its own right. In this paper we present our approach in selecting the most appropriate value based requirements prioritization framework as per the requirements of our stakeholders. Based on our analysis a single framework was selected, validated by requirements engineers and project managers and deployed for company-wide use by a major IT player in India.