Problems in handling NFRTerm Paper (as-is) problem statement

BY

A JAYKUMAR ASWATHAPPA ( AXA134730@UTDALL AS .EDU)

CS /SE 6361 EXECUT IVE MASTER ’S OF SC IENCE IN SOFTWARE ENGINEER ING

UNDER THE GU IDANCE OF DR. L AWRENCE CHUNG

UNIVERS ITY OF TEXAS AT DALL AS

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