Evaluation of non functional requirements in a request for proposal (RFP)

Yasuhiro Saito, Akito Monden, Kenichi Matsumoto

Research output: Contribution to conferencePaperpeer-review

6 Citations (Scopus)

Abstract

In the beginning of a contracted based software development project, the RFP is provided by a software user company and used as an initial system requirements specification to ask software developer companies to propose their technical plans to fulfill the requirements. In this process, it is very important to evaluate the quality of the RFP to make sure that basic user requirements are written enough. Especially, non-functional requirements (NFRs) are important since the system architecture greatly depends on the NFRs such as response time and security issues. This paper proposes a simple evaluation model of NFRs included in the RFP, mainly focusing on the user maintenance and operation issues. This model consists of NFR categories, NFR metrics, description level grading and weight to each NFR. As a case study, RFPs of 29 projects were evaluated by the proposed model. As a result, we confirmed that the model could identify poorly-written NFR aspects in the RFP, which need refinement before asking the developer company for a proposal.

Original languageEnglish
Pages106-111
Number of pages6
DOIs
Publication statusPublished - 2012
Externally publishedYes
Event2012 Joint Conference of the 22nd International Workshop on Software Measurement, IWSM 2012 and the 2012 7th International Conference on Software Process and Product Measurement, MENSURA 2012 - Assisi, Italy
Duration: Oct 17 2012Oct 19 2012

Other

Other2012 Joint Conference of the 22nd International Workshop on Software Measurement, IWSM 2012 and the 2012 7th International Conference on Software Process and Product Measurement, MENSURA 2012
Country/TerritoryItaly
CityAssisi
Period10/17/1210/19/12

Keywords

  • RFP
  • Requirements evaluation

ASJC Scopus subject areas

  • Software

Fingerprint

Dive into the research topics of 'Evaluation of non functional requirements in a request for proposal (RFP)'. Together they form a unique fingerprint.

Cite this