Requirements Engineering:
We live in a commercial world where much of our work is undertaken through a project -oriented approach. This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver. Computing is no differen...
Gespeichert in:
| Hauptverfasser: | , , |
|---|---|
| Format: | Elektronisch E-Book |
| Sprache: | English |
| Veröffentlicht: |
London
Springer London
2002
|
| Ausgabe: | 1st ed. 2002 |
| Schriftenreihe: | Practitioner Series
|
| Schlagworte: | |
| Online-Zugang: | UBY01 Volltext |
| Zusammenfassung: | We live in a commercial world where much of our work is undertaken through a project -oriented approach. This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver. Computing is no different in this regard, and so in order to organize our activities, we need to know what it is that is to be delivered. Hence Requirements Engineering, an organized approach to determining what is required in the project/ system that is being undertaken. There are some problems with the idea of Requirements Engineering, which I have on previous occasions encapsulated in a single sentence called 'The Mock Theorem of Information Systems' which states 'There exists some point in time when everyone involved in the system knows what they want and agrees with everyone else' Clearly nonsense (how would you know what everyone is agreeing to for example?). But in order to build a system on a project basis, this sentence has to be assumed to be true (either explicitly, or even worse, implicitly). Then Requirements Engineering can be made to work, and the correct prod uct/ system delivered by the project. However, we do not have an established alternative to the project approach, and the business world is used to projects. So Requirements Engineering is necessary, but it needs tempering to allow for the desired certainty actually being unknown |
| Beschreibung: | 1 Online-Ressource (XXIII, 216 p. 177 illus) |
| ISBN: | 9781447137306 |
| DOI: | 10.1007/978-1-4471-3730-6 |
Internformat
MARC
| LEADER | 00000nmm a2200000zc 4500 | ||
|---|---|---|---|
| 001 | BV047064164 | ||
| 003 | DE-604 | ||
| 005 | 00000000000000.0 | ||
| 007 | cr|uuu---uuuuu | ||
| 008 | 201216s2002 |||| o||u| ||||||eng d | ||
| 020 | |a 9781447137306 |9 978-1-4471-3730-6 | ||
| 024 | 7 | |a 10.1007/978-1-4471-3730-6 |2 doi | |
| 035 | |a (ZDB-2-SCS)978-1-4471-3730-6 | ||
| 035 | |a (OCoLC)1227482718 | ||
| 035 | |a (DE-599)BVBBV047064164 | ||
| 040 | |a DE-604 |b ger |e aacr | ||
| 041 | 0 | |a eng | |
| 049 | |a DE-706 | ||
| 082 | 0 | |a 005.1 |2 23 | |
| 084 | |a ST 230 |0 (DE-625)143617: |2 rvk | ||
| 084 | |a ST 237 |0 (DE-625)143623: |2 rvk | ||
| 100 | 1 | |a Hull, Elizabeth |e Verfasser |4 aut | |
| 245 | 1 | 0 | |a Requirements Engineering |c by Elizabeth Hull, Ken Jackson, Jeremy Dick |
| 250 | |a 1st ed. 2002 | ||
| 264 | 1 | |a London |b Springer London |c 2002 | |
| 300 | |a 1 Online-Ressource (XXIII, 216 p. 177 illus) | ||
| 336 | |b txt |2 rdacontent | ||
| 337 | |b c |2 rdamedia | ||
| 338 | |b cr |2 rdacarrier | ||
| 490 | 0 | |a Practitioner Series | |
| 520 | |a We live in a commercial world where much of our work is undertaken through a project -oriented approach. This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver. Computing is no different in this regard, and so in order to organize our activities, we need to know what it is that is to be delivered. Hence Requirements Engineering, an organized approach to determining what is required in the project/ system that is being undertaken. There are some problems with the idea of Requirements Engineering, which I have on previous occasions encapsulated in a single sentence called 'The Mock Theorem of Information Systems' which states 'There exists some point in time when everyone involved in the system knows what they want and agrees with everyone else' Clearly nonsense (how would you know what everyone is agreeing to for example?). But in order to build a system on a project basis, this sentence has to be assumed to be true (either explicitly, or even worse, implicitly). Then Requirements Engineering can be made to work, and the correct prod uct/ system delivered by the project. However, we do not have an established alternative to the project approach, and the business world is used to projects. So Requirements Engineering is necessary, but it needs tempering to allow for the desired certainty actually being unknown | ||
| 650 | 4 | |a Software Engineering | |
| 650 | 4 | |a System Performance and Evaluation | |
| 650 | 4 | |a Computer System Implementation | |
| 650 | 4 | |a User Interfaces and Human Computer Interaction | |
| 650 | 4 | |a Software engineering | |
| 650 | 4 | |a Computer system failures | |
| 650 | 4 | |a Architecture, Computer | |
| 650 | 4 | |a User interfaces (Computer systems) | |
| 650 | 0 | 7 | |a Requirements engineering |0 (DE-588)4213997-1 |2 gnd |9 rswk-swf |
| 689 | 0 | 0 | |a Requirements engineering |0 (DE-588)4213997-1 |D s |
| 689 | 0 | |5 DE-604 | |
| 700 | 1 | |a Jackson, Ken |4 aut | |
| 700 | 1 | |a Dick, Jeremy |4 aut | |
| 776 | 0 | 8 | |i Erscheint auch als |n Druck-Ausgabe |z 9781852335779 |
| 776 | 0 | 8 | |i Erscheint auch als |n Druck-Ausgabe |z 9781447137313 |
| 856 | 4 | 0 | |u https://doi.org/10.1007/978-1-4471-3730-6 |x Verlag |z URL des Eerstveröffentlichers |3 Volltext |
| 912 | |a ZDB-2-SCS | ||
| 940 | 1 | |q ZDB-2-SCS_2000/2004 | |
| 999 | |a oai:aleph.bib-bvb.de:BVB01-032471276 | ||
| 966 | e | |u https://doi.org/10.1007/978-1-4471-3730-6 |l UBY01 |p ZDB-2-SCS |q ZDB-2-SCS_2000/2004 |x Verlag |3 Volltext | |
Datensatz im Suchindex
| _version_ | 1804182061826703360 |
|---|---|
| adam_txt | |
| any_adam_object | |
| any_adam_object_boolean | |
| author | Hull, Elizabeth Jackson, Ken Dick, Jeremy |
| author_facet | Hull, Elizabeth Jackson, Ken Dick, Jeremy |
| author_role | aut aut aut |
| author_sort | Hull, Elizabeth |
| author_variant | e h eh k j kj j d jd |
| building | Verbundindex |
| bvnumber | BV047064164 |
| classification_rvk | ST 230 ST 237 |
| collection | ZDB-2-SCS |
| ctrlnum | (ZDB-2-SCS)978-1-4471-3730-6 (OCoLC)1227482718 (DE-599)BVBBV047064164 |
| dewey-full | 005.1 |
| dewey-hundreds | 000 - Computer science, information, general works |
| dewey-ones | 005 - Computer programming, programs, data, security |
| dewey-raw | 005.1 |
| dewey-search | 005.1 |
| dewey-sort | 15.1 |
| dewey-tens | 000 - Computer science, information, general works |
| discipline | Informatik |
| discipline_str_mv | Informatik |
| doi_str_mv | 10.1007/978-1-4471-3730-6 |
| edition | 1st ed. 2002 |
| format | Electronic eBook |
| fullrecord | <?xml version="1.0" encoding="UTF-8"?><collection xmlns="http://www.loc.gov/MARC21/slim"><record><leader>03507nmm a2200577zc 4500</leader><controlfield tag="001">BV047064164</controlfield><controlfield tag="003">DE-604</controlfield><controlfield tag="005">00000000000000.0</controlfield><controlfield tag="007">cr|uuu---uuuuu</controlfield><controlfield tag="008">201216s2002 |||| o||u| ||||||eng d</controlfield><datafield tag="020" ind1=" " ind2=" "><subfield code="a">9781447137306</subfield><subfield code="9">978-1-4471-3730-6</subfield></datafield><datafield tag="024" ind1="7" ind2=" "><subfield code="a">10.1007/978-1-4471-3730-6</subfield><subfield code="2">doi</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(ZDB-2-SCS)978-1-4471-3730-6</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(OCoLC)1227482718</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(DE-599)BVBBV047064164</subfield></datafield><datafield tag="040" ind1=" " ind2=" "><subfield code="a">DE-604</subfield><subfield code="b">ger</subfield><subfield code="e">aacr</subfield></datafield><datafield tag="041" ind1="0" ind2=" "><subfield code="a">eng</subfield></datafield><datafield tag="049" ind1=" " ind2=" "><subfield code="a">DE-706</subfield></datafield><datafield tag="082" ind1="0" ind2=" "><subfield code="a">005.1</subfield><subfield code="2">23</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">ST 230</subfield><subfield code="0">(DE-625)143617:</subfield><subfield code="2">rvk</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">ST 237</subfield><subfield code="0">(DE-625)143623:</subfield><subfield code="2">rvk</subfield></datafield><datafield tag="100" ind1="1" ind2=" "><subfield code="a">Hull, Elizabeth</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="245" ind1="1" ind2="0"><subfield code="a">Requirements Engineering</subfield><subfield code="c">by Elizabeth Hull, Ken Jackson, Jeremy Dick</subfield></datafield><datafield tag="250" ind1=" " ind2=" "><subfield code="a">1st ed. 2002</subfield></datafield><datafield tag="264" ind1=" " ind2="1"><subfield code="a">London</subfield><subfield code="b">Springer London</subfield><subfield code="c">2002</subfield></datafield><datafield tag="300" ind1=" " ind2=" "><subfield code="a">1 Online-Ressource (XXIII, 216 p. 177 illus)</subfield></datafield><datafield tag="336" ind1=" " ind2=" "><subfield code="b">txt</subfield><subfield code="2">rdacontent</subfield></datafield><datafield tag="337" ind1=" " ind2=" "><subfield code="b">c</subfield><subfield code="2">rdamedia</subfield></datafield><datafield tag="338" ind1=" " ind2=" "><subfield code="b">cr</subfield><subfield code="2">rdacarrier</subfield></datafield><datafield tag="490" ind1="0" ind2=" "><subfield code="a">Practitioner Series</subfield></datafield><datafield tag="520" ind1=" " ind2=" "><subfield code="a">We live in a commercial world where much of our work is undertaken through a project -oriented approach. This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver. Computing is no different in this regard, and so in order to organize our activities, we need to know what it is that is to be delivered. Hence Requirements Engineering, an organized approach to determining what is required in the project/ system that is being undertaken. There are some problems with the idea of Requirements Engineering, which I have on previous occasions encapsulated in a single sentence called 'The Mock Theorem of Information Systems' which states 'There exists some point in time when everyone involved in the system knows what they want and agrees with everyone else' Clearly nonsense (how would you know what everyone is agreeing to for example?). But in order to build a system on a project basis, this sentence has to be assumed to be true (either explicitly, or even worse, implicitly). Then Requirements Engineering can be made to work, and the correct prod uct/ system delivered by the project. However, we do not have an established alternative to the project approach, and the business world is used to projects. So Requirements Engineering is necessary, but it needs tempering to allow for the desired certainty actually being unknown</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Software Engineering</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">System Performance and Evaluation</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Computer System Implementation</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">User Interfaces and Human Computer Interaction</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Software engineering</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Computer system failures</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Architecture, Computer</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">User interfaces (Computer systems)</subfield></datafield><datafield tag="650" ind1="0" ind2="7"><subfield code="a">Requirements engineering</subfield><subfield code="0">(DE-588)4213997-1</subfield><subfield code="2">gnd</subfield><subfield code="9">rswk-swf</subfield></datafield><datafield tag="689" ind1="0" ind2="0"><subfield code="a">Requirements engineering</subfield><subfield code="0">(DE-588)4213997-1</subfield><subfield code="D">s</subfield></datafield><datafield tag="689" ind1="0" ind2=" "><subfield code="5">DE-604</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Jackson, Ken</subfield><subfield code="4">aut</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Dick, Jeremy</subfield><subfield code="4">aut</subfield></datafield><datafield tag="776" ind1="0" ind2="8"><subfield code="i">Erscheint auch als</subfield><subfield code="n">Druck-Ausgabe</subfield><subfield code="z">9781852335779</subfield></datafield><datafield tag="776" ind1="0" ind2="8"><subfield code="i">Erscheint auch als</subfield><subfield code="n">Druck-Ausgabe</subfield><subfield code="z">9781447137313</subfield></datafield><datafield tag="856" ind1="4" ind2="0"><subfield code="u">https://doi.org/10.1007/978-1-4471-3730-6</subfield><subfield code="x">Verlag</subfield><subfield code="z">URL des Eerstveröffentlichers</subfield><subfield code="3">Volltext</subfield></datafield><datafield tag="912" ind1=" " ind2=" "><subfield code="a">ZDB-2-SCS</subfield></datafield><datafield tag="940" ind1="1" ind2=" "><subfield code="q">ZDB-2-SCS_2000/2004</subfield></datafield><datafield tag="999" ind1=" " ind2=" "><subfield code="a">oai:aleph.bib-bvb.de:BVB01-032471276</subfield></datafield><datafield tag="966" ind1="e" ind2=" "><subfield code="u">https://doi.org/10.1007/978-1-4471-3730-6</subfield><subfield code="l">UBY01</subfield><subfield code="p">ZDB-2-SCS</subfield><subfield code="q">ZDB-2-SCS_2000/2004</subfield><subfield code="x">Verlag</subfield><subfield code="3">Volltext</subfield></datafield></record></collection> |
| id | DE-604.BV047064164 |
| illustrated | Not Illustrated |
| index_date | 2024-07-03T16:12:22Z |
| indexdate | 2024-07-10T09:01:34Z |
| institution | BVB |
| isbn | 9781447137306 |
| language | English |
| oai_aleph_id | oai:aleph.bib-bvb.de:BVB01-032471276 |
| oclc_num | 1227482718 |
| open_access_boolean | |
| owner | DE-706 |
| owner_facet | DE-706 |
| physical | 1 Online-Ressource (XXIII, 216 p. 177 illus) |
| psigel | ZDB-2-SCS ZDB-2-SCS_2000/2004 ZDB-2-SCS ZDB-2-SCS_2000/2004 |
| publishDate | 2002 |
| publishDateSearch | 2002 |
| publishDateSort | 2002 |
| publisher | Springer London |
| record_format | marc |
| series2 | Practitioner Series |
| spelling | Hull, Elizabeth Verfasser aut Requirements Engineering by Elizabeth Hull, Ken Jackson, Jeremy Dick 1st ed. 2002 London Springer London 2002 1 Online-Ressource (XXIII, 216 p. 177 illus) txt rdacontent c rdamedia cr rdacarrier Practitioner Series We live in a commercial world where much of our work is undertaken through a project -oriented approach. This has the advantage of determining the cost and time of the project to be undertaken, which in their turn are based on the knowledge of what the project is to deliver. Computing is no different in this regard, and so in order to organize our activities, we need to know what it is that is to be delivered. Hence Requirements Engineering, an organized approach to determining what is required in the project/ system that is being undertaken. There are some problems with the idea of Requirements Engineering, which I have on previous occasions encapsulated in a single sentence called 'The Mock Theorem of Information Systems' which states 'There exists some point in time when everyone involved in the system knows what they want and agrees with everyone else' Clearly nonsense (how would you know what everyone is agreeing to for example?). But in order to build a system on a project basis, this sentence has to be assumed to be true (either explicitly, or even worse, implicitly). Then Requirements Engineering can be made to work, and the correct prod uct/ system delivered by the project. However, we do not have an established alternative to the project approach, and the business world is used to projects. So Requirements Engineering is necessary, but it needs tempering to allow for the desired certainty actually being unknown Software Engineering System Performance and Evaluation Computer System Implementation User Interfaces and Human Computer Interaction Software engineering Computer system failures Architecture, Computer User interfaces (Computer systems) Requirements engineering (DE-588)4213997-1 gnd rswk-swf Requirements engineering (DE-588)4213997-1 s DE-604 Jackson, Ken aut Dick, Jeremy aut Erscheint auch als Druck-Ausgabe 9781852335779 Erscheint auch als Druck-Ausgabe 9781447137313 https://doi.org/10.1007/978-1-4471-3730-6 Verlag URL des Eerstveröffentlichers Volltext |
| spellingShingle | Hull, Elizabeth Jackson, Ken Dick, Jeremy Requirements Engineering Software Engineering System Performance and Evaluation Computer System Implementation User Interfaces and Human Computer Interaction Software engineering Computer system failures Architecture, Computer User interfaces (Computer systems) Requirements engineering (DE-588)4213997-1 gnd |
| subject_GND | (DE-588)4213997-1 |
| title | Requirements Engineering |
| title_auth | Requirements Engineering |
| title_exact_search | Requirements Engineering |
| title_exact_search_txtP | Requirements Engineering |
| title_full | Requirements Engineering by Elizabeth Hull, Ken Jackson, Jeremy Dick |
| title_fullStr | Requirements Engineering by Elizabeth Hull, Ken Jackson, Jeremy Dick |
| title_full_unstemmed | Requirements Engineering by Elizabeth Hull, Ken Jackson, Jeremy Dick |
| title_short | Requirements Engineering |
| title_sort | requirements engineering |
| topic | Software Engineering System Performance and Evaluation Computer System Implementation User Interfaces and Human Computer Interaction Software engineering Computer system failures Architecture, Computer User interfaces (Computer systems) Requirements engineering (DE-588)4213997-1 gnd |
| topic_facet | Software Engineering System Performance and Evaluation Computer System Implementation User Interfaces and Human Computer Interaction Software engineering Computer system failures Architecture, Computer User interfaces (Computer systems) Requirements engineering |
| url | https://doi.org/10.1007/978-1-4471-3730-6 |
| work_keys_str_mv | AT hullelizabeth requirementsengineering AT jacksonken requirementsengineering AT dickjeremy requirementsengineering |