1 / 7

Problems in handling NFR Term Paper (as-is) problem statement

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)

Download Presentation

Problems in handling NFR Term Paper (as-is) problem statement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  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 • 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

More Related