70 likes | 219 Views
Problems in handling NFR Term Paper (as-is) problem statement. By Ajaykumar ASWATHAPPA ( 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. Agenda. Introduction Problem (as-is)
E N D
Problems in handling NFRTerm Paper (as-is) problem statement By Ajaykumar ASWATHAPPA (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
Agenda • Introduction • Problem (as-is) • References
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
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
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
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
References • ExploringProblems 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-diagram • http://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