1. Problems in handling NFR Term Paper (as-is) problem statement BY AJAYKUMAR ASWATHAPPA (AXA134730@UTDALLAS.EDU)AXA134730@UTDALLAS.EDU CS/SE 6361 EXECUTIVE MASTER’S OF SCIENCE IN SOFTWARE ENGINEERING UNDER THE GUIDANCE OF DR. LAWRENCE CHUNG UNIVERSITY OF TEXAS AT DALLAS

2. Agenda Introduction Problem (as-is) References

3. Introduction IEEE defines Non-Functional Requirements as “a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints, and software quality attributes” Testing of Non Functional Requirement still remains a complex and ambiguous area NFR handling is not clearly defined in most of the projects Non-functional requirements often have to do with performance, correctness, maintainability, interoperability, portability, and so on NFRs introduce quality characteristics, but they also represent constraints under which the system must operate NFR becomes more crucial for real time or mission critical software

4. Problem (as-is) NFR are handles informally, confusingly, intermingled with other Functional requirement in SRS NFRs are often overlooked and not clearly specified in requirements documentations Identification and isolation of NFRs are a problem, it becomes important for a Business critical system Informal treatment of NFR, explicit dealing of NFR is missing in most systems unless they are mission critical NFR are not mapped directly and explicitly from requirements engineering to implementation Conventional Testing Methodology do not handle NFR attributes properly

5. Problem (as-is) Lack of stakeholder interactions introduces gap in NFR Layer 1: Stakeholders closely involved in the creation of the product, which could be a new system or a new process. Examples may include the project manager, software developer, business analyst, etc Layer 2: Stakeholders whose work changes when the solution is defined. For example, end users. Layer 3: Sponsors, executives/marketing who interact with the system Layer 4: External Stakeholders such as regulators, government, suppliers and the like

6. Problem (as-is) Usability issues are found late in the UAT phase due to lack of early involvement of end users Performance factors might not be covered well during earlier interactions with customers Portability factor – how much of the system functionality is portable Security Vs Performance

7. References Exploring Problems and Solutions in estimating Testing Effort for Non Functional Requirement Council for Innovative Research, www.ijctonline.com ISSN: 2277-3061. Volume 3 No. 2, OCT, 2012 A M. R. e. Laleau, "A Survey of Non-Functional Requirements in Software Development process,” October 2008. TR-LACL-2008-7. http://www.ibm.com/developerworks/webservices/library/ws-soa-nonfunctional/ http://businessanalystlearnings.com/ba-techniques/2013/1/22/how-to-draw-a-stakeholder-onion- diagramhttp://businessanalystlearnings.com/ba-techniques/2013/1/22/how-to-draw-a-stakeholder-onion- diagram http://blog.enfocussolutions.com/Powering_Requirements_Success/bid/105796/Stakeholder- Role-in-the-Software-Development-Lifecyclehttp://blog.enfocussolutions.com/Powering_Requirements_Success/bid/105796/Stakeholder- Role-in-the-Software-Development-Lifecycle http://trese.cs.utwente.nl/AOSD-EarlyAspectsWS/Papers/Brito.pdf