PUT Software Engineering Teamhttp://se.cs.put.poznan.pl
These are the search results for the query, showing results 1 to 15.

HAZOP-based identification of events in use caseshttp://se.cs.put.poznan.pl/publikacje/h4u2013 Completeness is one of the main quality attributes of requirements specifications. If functional requirements are expressed as use cases, one can be interested in event completeness. A use case is event complete if it contains description of all the events that can happen when executing the use case. Missing events in any use case can lead to higher project costs. Thus, the question arises of what is a good method of identification of events in use cases and what accuracy and review speed one can expect from it. The goal of this study was to check if (1) HAZOP-based event identification is more effective than ad hoc review and (2) what is the review speed of these two approaches. Two controlled experiments were conducted in order to evaluate ad hoc approach and H4U method to event identification. The first experiment included 18 students, while the second experiment was conducted with the help of 82 professionals. In both cases, accuracy and review speed of the investigated methods were measured and analyzed. Moreover, the usage of HAZOP keywords was analyzed. In both experiments, a benchmark specification based on use cases was used. The first experiment with students showed that a HAZOP-based review is more effective in event identification than ad hoc review and this result is statistically significant. However, the reviewing speed of HAZOP-based reviews is lower. The second experiment with professionals confirmed these results. These experiments showed also that event completeness is hard to achieve. It on average ranged from 0.15 to 0.26. HAZOP-based identification of events in use cases is an useful alternative to ad hoc reviews. It can achieve higher event completeness at the cost of an increase in effort.No publishermochodekrequirements engineeringsoftware qualitycontrolled experimentuse cases2016-08-20T17:31:17ZArticle ReferenceTowards Use-Cases Benchmarkhttp://se.cs.put.poznan.pl/publikacje/alchimowicz-2008 In the paper an approach to developing a use-cases benchmark is presented. The benchmark itself is a referential use-case-based requirements specification, which has a typical profile observed in real projects. To obtain this profile an extensive analysis of 432 use cases coming from 11 projects was performed. Because the developed specification represents those found in real projects, it might be used in order to present, test, and verify methods and tools for use-case analysis. This is especially important because industrial specifications are in most cases confident, and they might not be used by researchers who would like to replicate studies performed by their colleagues.No publishermochodekmetricsrequirements engineeringbenchmarkuse cases2011-08-11T07:44:14ZInproceedings ReferenceRA 04/10: Constructing Partial Domain-Models for Functional Size Measurement with TTPointshttp://se.cs.put.poznan.pl/publikacje/ra4-10 No publishermochodekttpointsdomain modelrequirements engineeringSRSuse casesmodel2010-09-13T12:44:26ZTechreport ReferenceTransactions in Use Cases, Non-functional Requirements, and Architectural Decisionshttp://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/transactions-in-use-cases-nfr-and-architectural-decisions Architectural decisions are usually considered to be influenced mainly by non-functional requirements (NFRs). It is difficult to disagree with such thesis. However, some of the decisions are not directly driven by NFRs, but by the functionality of the system. It can also happen that some of the NFRs are not explicitly defined. In this entry, you can find a checklist containing 20 questions regarding functional requirements that can help you investigate required capabilities of a system architecture.No publishermochodekrequirements engineeringarchitectural knowledgearchitecture evaluationuse cases2010-09-04T12:25:44ZBlog EntrySpecyfikacja wymagań dla systemów informatycznych http://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/specyfikacja-wymagan-dla-systemow-informatycznych-1 Właśnie otrzymaliśmy zgodę na publikację wyników projektu realizowanego we współpracy z Urzędem Miasta Poznania, którego celem było dostarczenie zestawu wytycznych odnośnie tworzenia specyfikacji wymagań dla systemów informatycznych (zwłaszcza w modelu przetargowym)No publishermochodekquality attributesrequirements engineeringuse case diagramSRSuse casesieee830:19982010-03-25T11:23:00ZBlog EntrySpecyfikacja wymagań dla systemów informatycznychhttp://se.cs.put.poznan.pl/projekty/konsulting/um-srs Celem projektu, realizowanego we współpracy z Urzędem Miasta Poznania, było dostarczenie zestawu wytycznych odnośnie tworzenia specyfikacji wymagań dla systemów informatycznych (zwłaszcza w modelu przetargowym)No publishermochodekrequirements engineeringiso9126use cases2011-05-08T19:45:22ZRich documentCRUD Pattern in Use Caseshttp://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/crud-pattern-in-use-cases If you have ever been writing use cases for a data-oriented system (i.e. CMS), you have probably noticed that there is a problem with the large number of use cases like "Add an article", "Remove an article" etc. If you have all CRUD operations available for all objects in the system, you can finish with up to 4 x number-of-objects of use cases. You can reduce this number by introducing the CRUD pattern, which I would like to present you in this blog entry.No publishermochodekpatternuse case diagramrequirements engineeringuse casesuml2010-04-07T19:35:00ZBlog EntryUse-Case Relations - Diagram and Texthttp://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/ucd-and-uc In this blog entry, I would like to show you how the relations (include, and extend) between use cases are presented on use case diagrams and how to use them in textual representations of use cases.No publishermochodekrequirements engineeringuse casesuse case diagramuml2010-01-24T09:11:47ZBlog EntryUse Case Diagramhttp://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/use-case-diagram Use cases were Ivar Jacobson's contribution to the UML notation. Although they are in most cases presented in a textual form, there is a special diagram in UML called Use Case Diagram (UCD), which is used to present their structure and associations with actors.
In this article I will try to present you all necessary information to use UCD effectively.No publishermochodekrequirements engineeringuse casesuse case diagramuml2009-12-22T09:54:15ZBlog EntryIntroduction to Use Caseshttp://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/introduction-to-use-cases Use cases, introduced by Ivar Jacobson more than 20 years ago, are used to capture user (actor) point of view while describing functional requirements of the system. In this brief article I would like to present you an overview of them (what are they, what are the most important parts of use-case model etc.)No publishermochodekrequirements engineeringuse cases2009-12-19T12:05:19ZBlog EntryEnhancing Use-Case-Based Effort Estimation with Transaction Types (presentation)http://se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/enhancing-use-case-based-effort-estimation-with-transaction-types Recently we have conducted some research regarding use-case-based effort estimation. Results were presented at CEE-SET'09 conference. If you would like to read how knowledge about use-case transactions semantics can help in estimating effort, go ahead and see the presentation. If you like the idea you can find more information in the paper.No publishermochodekeffort estimationuse case pointsttpointsrequirements engineeringuse casesuse-case transaction2010-09-04T11:21:15ZBlog EntryInżynieria wymagań (Polish)http://se.cs.put.poznan.pl/knowledge-base/forum-english/inzynieria-wymagan Tutaj możesz dyskutować na tematy związane z inżynierią wymagańNo publishermochodekrequirements engineering2009-10-16T12:25:46ZForumRequirements Engineering (English)http://se.cs.put.poznan.pl/knowledge-base/forum-english/requirements-engineering Here you can discuss all topics related to requirements engineeringNo publishermochodekrequirements engineering2009-10-16T12:23:15ZForumUC Workbench – A Tool for Writing Use Cases and Generating Mockupshttp://se.cs.put.poznan.pl/publikacje/olek2005 Agile methodologies are based on effective communication with the customer. The ideal case is XP s on-site customer. Unfortunately, in practice customer representatives are too busy to work with the development team all the time. Moreover, frequently there are many of them and each representative has only partial domain knowledge. To cope with this we introduced to our projects a proxy-customer role resembling RUP s Analyst and we equipped him with a tool, called UC Workbench, that supports the communication with the customer representatives and the developers. Analyst collects user stories from customer representatives and translates them into use cases. UC Workbench contains among other things a use-case editor and a generator of mockups (a mockup generated by UC Workbench animates use-cases and illustrates them with screen designs).No publishermochodekrequirements engineeringuc workbenchuse cases2009-09-09T06:55:23ZInproceedings ReferenceAutomatic Transactions Identification in Use Caseshttp://se.cs.put.poznan.pl/publikacje/ochodek-2008 Od początku lat 90-tych ubiegłego stulecia, przypadki użycia stały się nieformalnych standardem przedstawiania wymagań funkcjonalnych. Gwałtowny wzrost popularności zaawocował wieloma różnymi podejściami do ich prezentacji oraz stylami ich pisania. Niestety, ta różnorodność sprawia, że automatyczne przetwarzanie przypadków użycia jest bardzo trudne. Ten problem może być zniwelowany poprzez wykorzystanie koncepcji transakcji, która jest zdefiniowana jako atomowej część scenariusza przypadku użycia. W artykule prezentujemy podejście do automatycznego wykrywania transakcji w przypadkach użycia, poprzez analizę języka naturalnego (NLP). Proponowane rozwiązanie zostało zaimplementowane w postaci prototypowego narzędzia UCTD i wstępnie zweryfikowane.No publishermochodekeffort estimationuse case pointsrequirements engineeringnatural language processinguse casesuse-case transaction2009-09-08T06:25:39ZInproceedings Reference