View in EDS PDF Full Text

Task descriptions versus use cases.

Saved in:
Bibliographic Details
Title: Task descriptions versus use cases.
Authors: Lauesen, Soren1 slauesen@itu.dk, Kuhail, Mohammad1 moak@itu.dk
Source: Requirements Engineering. Mar2012, Vol. 17 Issue 1, p3-18. 16p. 7 Charts.
Subjects: Use cases (Systems engineering), Requirements engineering, Technical specifications, Task analysis, Task assessment, Task performance
Abstract: Use cases are widely used as a substantial part of requirements, also when little programming is expected (COTS-based systems, Commercial-Off-The-Shelf). Are use cases effective as requirements? To answer this question, we invited professionals and researchers to specify requirements for the same project: Acquire a new system to support a hotline. Among the 15 replies, eight used traditional use cases that specified a dialog between user and system. Seven used a related technique, task description, which specified the customer's needs without specifying a dialog. It also allowed the analyst to specify problem requirements-problems to be handled by the new system. It turned out that the traditional use cases covered the customer's needs poorly in areas where improvement was important but difficult. Use cases also restricted the solution space severely. Tasks did not have these problems and allowed an easy comparison of solutions. [ABSTRACT FROM AUTHOR]
Copyright of Requirements Engineering is the property of Springer Nature and its content may not be copied or emailed to multiple sites without the copyright holder's express written permission. Additionally, content may not be used with any artificial intelligence tools or machine learning technologies. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)
Database: Engineering Source
FullText Links:
  – Type: pdflink
Text:
  Availability: 0
Header DbId: egs
DbLabel: Engineering Source
An: 71748626
AccessLevel: 6
PubType: Academic Journal
PubTypeId: academicJournal
PreciseRelevancyScore: 0
IllustrationInfo
Items – Name: Title
  Label: Title
  Group: Ti
  Data: Task descriptions versus use cases.
– Name: Author
  Label: Authors
  Group: Au
  Data: <searchLink fieldCode="AR" term="%22Lauesen%2C+Soren%22">Lauesen, Soren</searchLink><relatesTo>1</relatesTo><i> slauesen@itu.dk</i><br /><searchLink fieldCode="AR" term="%22Kuhail%2C+Mohammad%22">Kuhail, Mohammad</searchLink><relatesTo>1</relatesTo><i> moak@itu.dk</i>
– Name: TitleSource
  Label: Source
  Group: Src
  Data: <searchLink fieldCode="JN" term="%22Requirements+Engineering%22">Requirements Engineering</searchLink>. Mar2012, Vol. 17 Issue 1, p3-18. 16p. 7 Charts.
– Name: Subject
  Label: Subjects
  Group: Su
  Data: <searchLink fieldCode="DE" term="%22Use+cases+%28Systems+engineering%29%22">Use cases (Systems engineering)</searchLink><br /><searchLink fieldCode="DE" term="%22Requirements+engineering%22">Requirements engineering</searchLink><br /><searchLink fieldCode="DE" term="%22Technical+specifications%22">Technical specifications</searchLink><br /><searchLink fieldCode="DE" term="%22Task+analysis%22">Task analysis</searchLink><br /><searchLink fieldCode="DE" term="%22Task+assessment%22">Task assessment</searchLink><br /><searchLink fieldCode="DE" term="%22Task+performance%22">Task performance</searchLink>
– Name: Abstract
  Label: Abstract
  Group: Ab
  Data: Use cases are widely used as a substantial part of requirements, also when little programming is expected (COTS-based systems, Commercial-Off-The-Shelf). Are use cases effective as requirements? To answer this question, we invited professionals and researchers to specify requirements for the same project: Acquire a new system to support a hotline. Among the 15 replies, eight used traditional use cases that specified a dialog between user and system. Seven used a related technique, task description, which specified the customer's needs without specifying a dialog. It also allowed the analyst to specify problem requirements-problems to be handled by the new system. It turned out that the traditional use cases covered the customer's needs poorly in areas where improvement was important but difficult. Use cases also restricted the solution space severely. Tasks did not have these problems and allowed an easy comparison of solutions. [ABSTRACT FROM AUTHOR]
– Name: AbstractSuppliedCopyright
  Label:
  Group: Ab
  Data: <i>Copyright of Requirements Engineering is the property of Springer Nature and its content may not be copied or emailed to multiple sites without the copyright holder's express written permission. Additionally, content may not be used with any artificial intelligence tools or machine learning technologies. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract.</i> (Copyright applies to all Abstracts.)
PLink https://search.ebscohost.com/login.aspx?direct=true&site=eds-live&db=egs&AN=71748626
RecordInfo BibRecord:
  BibEntity:
    Identifiers:
      – Type: doi
        Value: 10.1007/s00766-011-0140-1
    Languages:
      – Code: eng
        Text: English
    PhysicalDescription:
      Pagination:
        PageCount: 16
        StartPage: 3
    Subjects:
      – SubjectFull: Use cases (Systems engineering)
        Type: general
      – SubjectFull: Requirements engineering
        Type: general
      – SubjectFull: Technical specifications
        Type: general
      – SubjectFull: Task analysis
        Type: general
      – SubjectFull: Task assessment
        Type: general
      – SubjectFull: Task performance
        Type: general
    Titles:
      – TitleFull: Task descriptions versus use cases.
        Type: main
  BibRelationships:
    HasContributorRelationships:
      – PersonEntity:
          Name:
            NameFull: Lauesen, Soren
      – PersonEntity:
          Name:
            NameFull: Kuhail, Mohammad
    IsPartOfRelationships:
      – BibEntity:
          Dates:
            – D: 01
              M: 03
              Text: Mar2012
              Type: published
              Y: 2012
          Identifiers:
            – Type: issn-print
              Value: 09473602
          Numbering:
            – Type: volume
              Value: 17
            – Type: issue
              Value: 1
          Titles:
            – TitleFull: Requirements Engineering
              Type: main
ResultId 1