|
| This Article | ||
| ||
| Share | ||
| Bibliographic References | ||
| Add to: | ||
| | ||
| Search | ||
| ||
| ASCII Text | x | ||
| Soren Lauesen, "Task Descriptions as Functional Requirements," IEEE Software, vol. 20, no. 2, pp. 58-65, March/April, 2003. | |||
| BibTex | x | ||
| @article{ 10.1109/MS.2003.1184169, author = {Soren Lauesen}, title = {Task Descriptions as Functional Requirements}, journal ={IEEE Software}, volume = {20}, number = {2}, issn = {0740-7459}, year = {2003}, pages = {58-65}, doi = {http://doi.ieeecomputersociety.org/10.1109/MS.2003.1184169}, publisher = {IEEE Computer Society}, address = {Los Alamitos, CA, USA}, } | |||
| RefWorks Procite/RefMan/Endnote | x | ||
| TY - MGZN JO - IEEE Software TI - Task Descriptions as Functional Requirements IS - 2 SN - 0740-7459 SP58 EP65 EPD - 58-65 A1 - Soren Lauesen, PY - 2003 KW - requirements KW - task descriptions KW - use cases KW - COTS KW - validation KW - business goals KW - tender process VL - 20 JA - IEEE Software ER - | |||
Many IT systems fail to satisfy business goals or support users efficiently, even when the system meets written requirements. Why? Usually because the requirements rather arbitrarily specify what a system shall do, and barely consider its context. Stakeholders cannot check that such requirements meet expectations. To remedy this situation, the Tasks & Support approach uses task descriptions that specify what the user and computer shall accomplish together without being explicit about who performs which parts of a task. The requirement is simply to support the identified tasks. Stakeholders can easily validate and later verify such requirements. This approach is just as successful for product development and large-scale work restructuring as it is for buying commercial off-the-shelf products. Although the resulting requirements are of higher quality than traditional requirements, they are much faster to produce.

