Name
Abstract | ||
|---|---|---|
Abstract. This paper presents common,weaknesses,of re- quirements documents,from commercial,software projects that frequently cause problems,in practice. Many docu- ments contain extensive, unstructured or even superfluous descriptions of details. At the same time, they lack a thor- ough description of the aim of the software system or one of its features. Such documents,are difficult to read and to work with andtheyunnecessarilyrestrict possible solutions. We argue that two quality criteria must be considered in additionto commoncriteria. First, requirementsdocuments should be based on a sound refinement of the main goals to concrete requirements. Secondly, they should follow the principle of minimality, i.e., no more details than necessary. In order to gain improvements in projects in practice, quality criteria must be communicated,to authors. For this purpose, we propose two visualizations, which describe the information structure of the document,in a technology-free and domain-independentmanner. Keywords: Software Requirements, Requirements Docu- |
Year | Venue | Keywords |
|---|---|---|
2008 | Software Engineering Research and Practice | software requirements,software systems |
Field | DocType | Citations |
Software engineering,Computer science,Requirements analysis,Risk analysis (engineering),Requirements management,Software quality control,Business requirements,Requirement,Requirement prioritization,Software requirements specification,Non-functional testing | Conference | 0 |
PageRank | References | Authors |
0.34 | 10 | 3 |
Name | Order | Citations | PageRank |
|---|---|---|---|
| Tobias Simon | 1 | 16 | 5.44 |
| Jonathan Streit | 2 | 57 | 4.02 |
| Markus Pizka | 3 | 260 | 20.24 |