The notion of Non Functional Requirement (NFR) of software system is not homogeneous. There is lack of consensus to answer questions as: What are they? How do they classify within the software development context? Also, knowing, how there are classified in the Web application development? In [1] we compared six Methodological approaches used for the development of Web applications in order to analyze how these approaches treat to Non-Functional Requirements (NFR); we conclude that: NFR are considered, but there is no consensus in their meaning. There are neither specifics techniques for elicitation of NFR Web nor uniform guidelines for the specification and validation. Some of the studied methodologies have tools to deal with NFR but they are specific to the process they support. There is a lack of consensus to establish within which phase of development lifetime cycle NFR are identified. The maturity of the Requirements Engineering process related to NFR seems insufficient to develop such applications. To overcome this shortcoming in the proper treatment of NFR demands new approaches or evolve the current approaches. Due to its importance, activities to capture, specification and validation of Web's NFR, must have specific guidelines and techniques for them. This work introduces processes to Elicitation and Specification of Web Applications NFR (quality and restrictions) using templates especially designed to capture and NFR specify. The proposed notions and processes are validated in a real project.
Introduction 2 restrictions, inasmuch as they restrict models design solution. Specification process proposes a Pattern to specify NFR in order to get correct, feasible, priorizables, non ambiguous NFR, and Web NFR Specification Template, output of specification process, which represent a model for Web Application NFR, pending of validation.
The NFR Matrix let trace each NFR with their origin and documents the state of each requirements during the Specification and Elicitation process. The possible states are: Negotiation, Analysis, Postponed, Rejected, Pending of validation. The process. Non linear, the Elicitation and Specification process are not isolated; they interact in order to knowledge capture, analysis, and description of NFR and Stakeholders negotiations.
The Requirement Engineer obtains the relevant knowledge of the problem domain related to NFR based on questions provided by NFR Elicitation Templates, and then the Requirement Engineer writes candidate requirements into NFR Matrix following the NFR Pattern. If there are requirements in conflict or requirements that needs a technical feasibility study, a state of Negotiations or Analysis is assigned respectably. The Requirement Engineer interacts with Stakeholders until all NFR within the Matrix have the final state of Postponed, Rejected or Pending of Validation.
The output of the Specification process (Web NFR Specification Template) is
elaborated with all NFR in Pending of Validation state, written in the NFR Matrix.
Study case. We have applied the described process on a real project ‘Indicators of
cranes and ships’ [
NFR capture was performed in parallel with FR through seven face to face meetings, emails and conference calls. Sixteen FR were identified and Thirty-six NFR (fifteen of quality type and twenty one restriction type).
As a result of our study research we can claim that the Elicitation and Specifications of NFR for Web Applications are possible whenever you count on a process and techniques suitable for this purpose.
Contributions. Elicitation and Specification Process of NFR for Web Application
includes guidelines and activities to capture, definition and specification of NFR, also
provides five templates particularly designed to support the process. The results from
the applying of the processes in a case study out of a real project ‘Indicators of cranes
and ships’ [