Examining the Relationships between Performance Requirements and "Not a Problem" Defect Reports

Missing or imprecise requirements can lead stakeholders to make incorrect assumptions. A "not a problem" defect report (NaP) describes a software behavior that a stakeholder regards as a problem while the developer believes this behavior is acceptable and chooses not to take any action. As...

Ausführliche Beschreibung

Gespeichert in:
Bibliographische Detailangaben
Hauptverfasser: Chih-Wei Ho, Williams, L., Robinson, B.
Format: Tagungsbericht
Sprache:eng
Schlagworte:
Online-Zugang:Volltext bestellen
Tags: Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
container_end_page 144
container_issue
container_start_page 135
container_title
container_volume
creator Chih-Wei Ho
Williams, L.
Robinson, B.
description Missing or imprecise requirements can lead stakeholders to make incorrect assumptions. A "not a problem" defect report (NaP) describes a software behavior that a stakeholder regards as a problem while the developer believes this behavior is acceptable and chooses not to take any action. As a result, a NaP wastes the time of the development team because resources are spent analyzing the problem but the quality of the software is not improved. Performance requirements specification and analysis are instance-based. System performance can change based upon the execution environment or usage patterns. To understand how the availability and precision of performance requirements can affect NaP occurrence rate, we conducted a case study on an embedded control module. We applied the performance refinement and evolution model to examine the relationship between each factor in the performance requirements and the corresponding NaP occurrence rate. Our findings show that precise specification of subjects or workloads lowers the occurrence rate of NaPs. Precise specification of measures or environments does not lower the occurrence rate of NaPs. Finally, the availability of performance requirements does not affect NaP occurrence rate in this case study.
doi_str_mv 10.1109/RE.2008.51
format Conference Proceeding
fullrecord <record><control><sourceid>ieee_6IE</sourceid><recordid>TN_cdi_ieee_primary_4685662</recordid><sourceformat>XML</sourceformat><sourcesystem>PC</sourcesystem><ieee_id>4685662</ieee_id><sourcerecordid>4685662</sourcerecordid><originalsourceid>FETCH-LOGICAL-i175t-5e15e77e427c5f12c520defa33190c38574c343e83e40d5c9c8d4d6987b2103b3</originalsourceid><addsrcrecordid>eNotzDtPwzAYhWGLi0QpXVhZrO4pn-_JiEq5SBVUFUhsleN8oUaNE2wj4N9TBGd5l0eHkHMGM8agulwvZhygnCl2QEZcCF5oKdkhOQWjKyUEVPKIjPYSCgPq5YRMUnqD_RQ3nOkR2Sy-bOeDD680b5GucWez70Pa-iHRGvMnYqArjG0fOxvcr3j_8BE7DDlRGxo6fegztXQV-3qH3ZReY4su793Qx5zOyHFrdwkn_x2T55vF0_yuWD7e3s-vloVnRuVCIVNoDEpunGoZd4pDg60VglXgRKmMdEIKLAVKaJSrXNnIRlelqTkDUYsxufj79Yi4GaLvbPzeSF0qrbn4ATm3VGo</addsrcrecordid><sourcetype>Publisher</sourcetype><iscdi>true</iscdi><recordtype>conference_proceeding</recordtype></control><display><type>conference_proceeding</type><title>Examining the Relationships between Performance Requirements and "Not a Problem" Defect Reports</title><source>IEEE Electronic Library (IEL) Conference Proceedings</source><creator>Chih-Wei Ho ; Williams, L. ; Robinson, B.</creator><creatorcontrib>Chih-Wei Ho ; Williams, L. ; Robinson, B.</creatorcontrib><description>Missing or imprecise requirements can lead stakeholders to make incorrect assumptions. A "not a problem" defect report (NaP) describes a software behavior that a stakeholder regards as a problem while the developer believes this behavior is acceptable and chooses not to take any action. As a result, a NaP wastes the time of the development team because resources are spent analyzing the problem but the quality of the software is not improved. Performance requirements specification and analysis are instance-based. System performance can change based upon the execution environment or usage patterns. To understand how the availability and precision of performance requirements can affect NaP occurrence rate, we conducted a case study on an embedded control module. We applied the performance refinement and evolution model to examine the relationship between each factor in the performance requirements and the corresponding NaP occurrence rate. Our findings show that precise specification of subjects or workloads lowers the occurrence rate of NaPs. Precise specification of measures or environments does not lower the occurrence rate of NaPs. Finally, the availability of performance requirements does not affect NaP occurrence rate in this case study.</description><identifier>ISSN: 1090-705X</identifier><identifier>ISBN: 0769533094</identifier><identifier>ISBN: 9780769533094</identifier><identifier>EISSN: 2332-6441</identifier><identifier>DOI: 10.1109/RE.2008.51</identifier><language>eng</language><publisher>IEEE</publisher><subject>Availability ; Computer science ; Delay ; Performance analysis ; Project management ; requirements engineering ; Software development management ; Software performance ; software performance requirements ; Software quality ; System performance ; Throughput</subject><ispartof>2008 16th IEEE International Requirements Engineering Conference, 2008, p.135-144</ispartof><woscitedreferencessubscribed>false</woscitedreferencessubscribed></display><links><openurl>$$Topenurl_article</openurl><openurlfulltext>$$Topenurlfull_article</openurlfulltext><thumbnail>$$Tsyndetics_thumb_exl</thumbnail><linktohtml>$$Uhttps://ieeexplore.ieee.org/document/4685662$$EHTML$$P50$$Gieee$$H</linktohtml><link.rule.ids>309,310,776,780,785,786,2052,27902,54895</link.rule.ids><linktorsrc>$$Uhttps://ieeexplore.ieee.org/document/4685662$$EView_record_in_IEEE$$FView_record_in_$$GIEEE</linktorsrc></links><search><creatorcontrib>Chih-Wei Ho</creatorcontrib><creatorcontrib>Williams, L.</creatorcontrib><creatorcontrib>Robinson, B.</creatorcontrib><title>Examining the Relationships between Performance Requirements and "Not a Problem" Defect Reports</title><title>2008 16th IEEE International Requirements Engineering Conference</title><addtitle>ICRE</addtitle><description>Missing or imprecise requirements can lead stakeholders to make incorrect assumptions. A "not a problem" defect report (NaP) describes a software behavior that a stakeholder regards as a problem while the developer believes this behavior is acceptable and chooses not to take any action. As a result, a NaP wastes the time of the development team because resources are spent analyzing the problem but the quality of the software is not improved. Performance requirements specification and analysis are instance-based. System performance can change based upon the execution environment or usage patterns. To understand how the availability and precision of performance requirements can affect NaP occurrence rate, we conducted a case study on an embedded control module. We applied the performance refinement and evolution model to examine the relationship between each factor in the performance requirements and the corresponding NaP occurrence rate. Our findings show that precise specification of subjects or workloads lowers the occurrence rate of NaPs. Precise specification of measures or environments does not lower the occurrence rate of NaPs. Finally, the availability of performance requirements does not affect NaP occurrence rate in this case study.</description><subject>Availability</subject><subject>Computer science</subject><subject>Delay</subject><subject>Performance analysis</subject><subject>Project management</subject><subject>requirements engineering</subject><subject>Software development management</subject><subject>Software performance</subject><subject>software performance requirements</subject><subject>Software quality</subject><subject>System performance</subject><subject>Throughput</subject><issn>1090-705X</issn><issn>2332-6441</issn><isbn>0769533094</isbn><isbn>9780769533094</isbn><fulltext>true</fulltext><rsrctype>conference_proceeding</rsrctype><creationdate>2008</creationdate><recordtype>conference_proceeding</recordtype><sourceid>6IE</sourceid><sourceid>RIE</sourceid><recordid>eNotzDtPwzAYhWGLi0QpXVhZrO4pn-_JiEq5SBVUFUhsleN8oUaNE2wj4N9TBGd5l0eHkHMGM8agulwvZhygnCl2QEZcCF5oKdkhOQWjKyUEVPKIjPYSCgPq5YRMUnqD_RQ3nOkR2Sy-bOeDD680b5GucWez70Pa-iHRGvMnYqArjG0fOxvcr3j_8BE7DDlRGxo6fegztXQV-3qH3ZReY4su793Qx5zOyHFrdwkn_x2T55vF0_yuWD7e3s-vloVnRuVCIVNoDEpunGoZd4pDg60VglXgRKmMdEIKLAVKaJSrXNnIRlelqTkDUYsxufj79Yi4GaLvbPzeSF0qrbn4ATm3VGo</recordid><startdate>200809</startdate><enddate>200809</enddate><creator>Chih-Wei Ho</creator><creator>Williams, L.</creator><creator>Robinson, B.</creator><general>IEEE</general><scope>6IE</scope><scope>6IL</scope><scope>CBEJK</scope><scope>RIE</scope><scope>RIL</scope></search><sort><creationdate>200809</creationdate><title>Examining the Relationships between Performance Requirements and "Not a Problem" Defect Reports</title><author>Chih-Wei Ho ; Williams, L. ; Robinson, B.</author></sort><facets><frbrtype>5</frbrtype><frbrgroupid>cdi_FETCH-LOGICAL-i175t-5e15e77e427c5f12c520defa33190c38574c343e83e40d5c9c8d4d6987b2103b3</frbrgroupid><rsrctype>conference_proceedings</rsrctype><prefilter>conference_proceedings</prefilter><language>eng</language><creationdate>2008</creationdate><topic>Availability</topic><topic>Computer science</topic><topic>Delay</topic><topic>Performance analysis</topic><topic>Project management</topic><topic>requirements engineering</topic><topic>Software development management</topic><topic>Software performance</topic><topic>software performance requirements</topic><topic>Software quality</topic><topic>System performance</topic><topic>Throughput</topic><toplevel>online_resources</toplevel><creatorcontrib>Chih-Wei Ho</creatorcontrib><creatorcontrib>Williams, L.</creatorcontrib><creatorcontrib>Robinson, B.</creatorcontrib><collection>IEEE Electronic Library (IEL) Conference Proceedings</collection><collection>IEEE Proceedings Order Plan All Online (POP All Online) 1998-present by volume</collection><collection>IEEE Xplore All Conference Proceedings</collection><collection>IEEE Electronic Library (IEL)</collection><collection>IEEE Proceedings Order Plans (POP All) 1998-Present</collection></facets><delivery><delcategory>Remote Search Resource</delcategory><fulltext>fulltext_linktorsrc</fulltext></delivery><addata><au>Chih-Wei Ho</au><au>Williams, L.</au><au>Robinson, B.</au><format>book</format><genre>proceeding</genre><ristype>CONF</ristype><atitle>Examining the Relationships between Performance Requirements and "Not a Problem" Defect Reports</atitle><btitle>2008 16th IEEE International Requirements Engineering Conference</btitle><stitle>ICRE</stitle><date>2008-09</date><risdate>2008</risdate><spage>135</spage><epage>144</epage><pages>135-144</pages><issn>1090-705X</issn><eissn>2332-6441</eissn><isbn>0769533094</isbn><isbn>9780769533094</isbn><abstract>Missing or imprecise requirements can lead stakeholders to make incorrect assumptions. A "not a problem" defect report (NaP) describes a software behavior that a stakeholder regards as a problem while the developer believes this behavior is acceptable and chooses not to take any action. As a result, a NaP wastes the time of the development team because resources are spent analyzing the problem but the quality of the software is not improved. Performance requirements specification and analysis are instance-based. System performance can change based upon the execution environment or usage patterns. To understand how the availability and precision of performance requirements can affect NaP occurrence rate, we conducted a case study on an embedded control module. We applied the performance refinement and evolution model to examine the relationship between each factor in the performance requirements and the corresponding NaP occurrence rate. Our findings show that precise specification of subjects or workloads lowers the occurrence rate of NaPs. Precise specification of measures or environments does not lower the occurrence rate of NaPs. Finally, the availability of performance requirements does not affect NaP occurrence rate in this case study.</abstract><pub>IEEE</pub><doi>10.1109/RE.2008.51</doi><tpages>10</tpages></addata></record>
fulltext fulltext_linktorsrc
identifier ISSN: 1090-705X
ispartof 2008 16th IEEE International Requirements Engineering Conference, 2008, p.135-144
issn 1090-705X
2332-6441
language eng
recordid cdi_ieee_primary_4685662
source IEEE Electronic Library (IEL) Conference Proceedings
subjects Availability
Computer science
Delay
Performance analysis
Project management
requirements engineering
Software development management
Software performance
software performance requirements
Software quality
System performance
Throughput
title Examining the Relationships between Performance Requirements and "Not a Problem" Defect Reports
url https://sfx.bib-bvb.de/sfx_tum?ctx_ver=Z39.88-2004&ctx_enc=info:ofi/enc:UTF-8&ctx_tim=2025-02-15T23%3A45%3A56IST&url_ver=Z39.88-2004&url_ctx_fmt=infofi/fmt:kev:mtx:ctx&rfr_id=info:sid/primo.exlibrisgroup.com:primo3-Article-ieee_6IE&rft_val_fmt=info:ofi/fmt:kev:mtx:book&rft.genre=proceeding&rft.atitle=Examining%20the%20Relationships%20between%20Performance%20Requirements%20and%20%22Not%20a%20Problem%22%20Defect%20Reports&rft.btitle=2008%2016th%20IEEE%20International%20Requirements%20Engineering%20Conference&rft.au=Chih-Wei%20Ho&rft.date=2008-09&rft.spage=135&rft.epage=144&rft.pages=135-144&rft.issn=1090-705X&rft.eissn=2332-6441&rft.isbn=0769533094&rft.isbn_list=9780769533094&rft_id=info:doi/10.1109/RE.2008.51&rft_dat=%3Cieee_6IE%3E4685662%3C/ieee_6IE%3E%3Curl%3E%3C/url%3E&disable_directlink=true&sfx.directlink=off&sfx.report_link=0&rft_id=info:oai/&rft_id=info:pmid/&rft_ieee_id=4685662&rfr_iscdi=true