Skip to main content
Log in

Requirement-oriented risk management for incremental software development

  • S.I.: Verifiability in Systems and Data Engineering
  • Published:
Innovations in Systems and Software Engineering Aims and scope Submit manuscript

Abstract

In incremental software development (ISD) functionalities are delivered incrementally and requirements keep on evolving across iterations. The requirements evolution involves the addition of new dependencies and conflicts among functional and non-functional requirements along with changes in priorities and dependency weights. This, in turn, demands refactoring the order of development of system components to minimize the impact of these changes. Neglecting the non-functional constraints in the software development process exposes it to risks that may accumulate across several iterations. In this research work, we propose a risk management framework for ISD processes that provides an estimate of risk exposure for the project when functional features are frozen while ignoring the associations with non-functional requirements. Our framework proposes suitable risk reduction strategies that work in tandem with the risk assessment module. We also provide a tool interface for our risk management framework.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12

Similar content being viewed by others

Notes

  1. https://github.com/FuncReq/RiskMonitor_Tool.

References

  1. Albadarneh A, Albadarneh I, Qusef A (2015) Risk management in agile software development: a comparative study. In: 2015 IEEE Jordan conference on applied electrical engineering and computing technologies (AEECT) pp 1–6 . https://doi.org/10.1109/AEECT.2015.7360573

  2. Ameller D, Franch X, Gómez C, Martínez-Fernández S, Araujo J, Biffl S, Cabot J, Cortellessa V, Méndez D, Moreira A, Muccini H, Vallecillo A, Wimmer M, Amaral V, Bühm W, Bruneliere H, Burgueño L, Goulão M, Teufl S, Berardinelli L (2019) Dealing with non-functional requirements in model-driven development: a survey. IEEE Trans Softw Eng. https://doi.org/10.1109/TSE.2019.2904476

    Article  Google Scholar 

  3. Asghar AR, Tabassum A, Bhatti SN, Jadi AM (2017) Impact and challenges of requirements elicitation prioritization in quality to agile process: scrum as a case scenario. In: 2017 International conference on communication technologies (ComTech) pp 50–55 . https://doi.org/10.1109/COMTECH.2017.8065749

  4. Barros M, Pitangueira A, Tonella P, Susi A, Maciel RS (2016) Risk-aware multi-stakeholder next release planning using multi-objective optimization. In: Daneva M, Pastor O (eds) Requirements engineering: foundation for software quality. REFSQ. https://doi.org/10.1007/978-3-319-30282-9_1

  5. Busetta P, Kifetew FM, Muñante D, Perini A, Siena A, Susi A (2017) Tool-supported collaborative requirements prioritisation. In: 41st IEEE Annual computer software and applications conference. COMPSAC, Turin, Italy vol 1, pp 180–189. https://doi.org/10.1109/COMPSAC.2017.243

  6. Chandani P, Gupta C (2018) Requirement risk prioritization using analytic hierarchy process: a gateway to identify risky requirements. In: 2018 Eleventh international conference on contemporary computing (IC3) pp 1–6 . https://doi.org/10.1109/IC3.2018.8530569

  7. Díaz J, Pérez J, Garbajosa J, Yagüe A (2013) Change-impact driven agile architecting. In: 2013 46th Hawaii international conference on system sciences, pp 4780–4789. https://doi.org/10.1109/HICSS.2013.127

  8. Gandhi RA, Lee S (2007) Visual analytics for requirements-driven risk assessment. In: Second international workshop on requirements engineering visualization (REV 2007). https://doi.org/10.1109/REV.2007.6

  9. Ghane K (2017) Quantitative planning and risk management of agile software development. In: 2017 IEEE technology engineering management conference (TEMSCON), pp 109–112 . https://doi.org/10.1109/TEMSCON.2017.7998362

  10. Guzmán L, Oriol M, Rodríguez P, Franch X, Jedlitschka A, Oivo M (2017) How can quality awareness support rapid software development? A research preview. Proceedings of 23rd international working conference requirements engineering: foundation for software quality. REFSQ, Essen, Germany, vol 10153, pp 167–173. https://doi.org/10.1007/978-3-319-54045-0_12

  11. Islam S (2009) Software development risk management model: a goal driven approach. Associat Comput Machinery. https://doi.org/10.1145/1595782.1595785

    Article  Google Scholar 

  12. Roy M, Deb N, Cortesi A, Chaki R, Chaki N (2021) Dynamic prioritization of software requirements for incremental software development. In: Accepted in 8th international doctoral symposium on applied computation and security systems (ACSS-2021)

  13. Roy M, Deb N, Cortesi A, Chaki R, Chaki N (2020) Nfr - aware prioritization of software requirements. Submitted in Wiley System Engineering Journal

  14. Sharma P, Dhir S (2016) Functional & non-functional requirement elicitation and risk assessment for agile processes. IJCTA 9:9005–9010

    Google Scholar 

  15. Tavares BG, da Silva CES, de Souza AD (2019) Practices to improve risk management in agile projects. Int J Softw Eng Knowl Eng 29(03):381–399. https://doi.org/10.1142/S0218194019500165

    Article  Google Scholar 

  16. Uzzafer M (2015) Measuring the risk of software projects. Int J Softw Eng Appl 9:247–262. https://doi.org/10.14257/ijseia.2015.9.11.23

  17. Wyatt V, DiStefano J, Chapman M, Aycoth E (2003) A metrics based approach for identifying requirements risks. In: Proceedings of 28th annual NASA goddard software engineering workshop, 2003, pp 23–28. https://doi.org/10.1109/SEW.2003.1270722

  18. Xiaosong L, Shushi L, Wenjun C, Songjiang F (2009) The application of risk matrix to software project risk management. Int Forum Inf Technol Appl 2:480–483. https://doi.org/10.1109/IFITA.2009.542

    Article  Google Scholar 

Download references

Acknowledgements

This work has been partially supported by the Project IN17MO07 “Formal Specification for Secured Software System”, under the Indo-Italian Executive Programme of Scientific and Technological Cooperation.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Mandira Roy.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Annex I

Annex I

The partial order tool prototype (available at\(^4\)Footnote 1) is the implementation of our proposed solution for risk management in a dynamic business environment. Figure 13 is an representation of the complete tool interface.

Fig. 13
figure 13

Tool interface

Fig. 14
figure 14

Requirement specification sections

Fig. 15
figure 15

NFR Priority, parameter & frozen requirement sections

Fig. 16
figure 16

Partial Order comparison & Risk Analysis

Fig. 17
figure 17

Unfreezing Requirements

Now we proceed to discuss the different components of the partial order tool.

  1. A.

    Requirement Specifications

    • Section for adding and modifying FR-NFR dependencies: Figure 14a potrays the section of the tool that allows the developers to add FRs, their associated NFRs and the corresponding dependency values as well. Apart from this, developers can also modify an existing entry and delete them as well. The table in the left in Fig. 14a displays the entries made by the user.

    • Section for adding and modifying NFR-NFR conflicts: Figure 14b illustrates the section of the tool that allows the developers to add NFR conflicts and also a numeric value to indicate the degree of conflict. Similarly here also developers can modify an existing entry and delete them as well. The table in the left in Fig. 14b displays the NFR conflicts entered by the user.

    • Section for adding and modifying FR Temporal dependency: Figure 14c represents the section of the tool that allows the developers to add temporal dependencies between the FRs. The developers can also delete an existing entry. The table in the left in Figure 14(c) displays the dependencies entered by the user.

    Once all the FR-NFR dependency, NFR-NFR conflicts and temporal dependencies among FR are added it needs to be saved and then the user can specify the priority values of the NFRs.

  2. B.

    NFR Priority Specification Figure 14a presents the section of the tool where the user can at first load the NFRs specified and then add a priority value corresponding to each NFR.

  3. C.

    Parameter Selection This section (refer to Fig. 14c) allows the developers to select one of the parameter, based on which the partial order(s) will be generated. In case of parameter Weighted Sum user needs to specify weights for conflict and NFR priority using the slider (as shown in the boxed portion Fig. 14c).

  4. D.

    Frozen requirements selection Figure 14b shows the section of the tool where user can specify the set of FRs that are to be frozen for the next increment of the software development process. The tool also provides provision for removing a FR from the list of frozen requirement. This will be helpful is doing risk analysis for different choices.

  5. E.

    Partial Order Generation Figure 16a displays the set of buttons that helps the user to generate optimal and alternate partial order. In Figure 16a buttons marked as A are used to generate optimal partial order as text and graph respectively. Similarly, in Fig. 16a buttons marked as B are used to generate alternate partial order as text and graph respectively.

  6. F.

    Risk Analysis Once both the partial orders are generated user can compare the two partial orders (using the button marked as C in Fig. 16a) and analyze the precedences that are being violated in the alternate partial order, when requirements are selected for freezing neglects the NFR constraints. The tool along with the conflicting precedences also displays the quantative risk exposure values. The button marked as D is ussed to generate the qualitative risk analysis report (refer to Fig. 8c).

  7. G.

    Unfreezing Requirements User have the provision to unfreeze requirements at any iteration (refer to the Unfreeze button marked as E in Fig. 16a). Unfreezing option lets user to select the increment from which requirements will be unfreezed (refer to Fig. 17a). Now after selecting the increment user can view the amount of risk that can be reduced by unfreezing different combinations of requirements from a particular increment. Figure 17c shows the risk reduced after unfreezing requirements.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Roy, M., Deb, N., Cortesi, A. et al. Requirement-oriented risk management for incremental software development. Innovations Syst Softw Eng 17, 187–204 (2021). https://doi.org/10.1007/s11334-021-00406-6

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s11334-021-00406-6

Keywords

Navigation