http://www.se.cs.put.poznan.pl These are the search results for the query, showing results 6 to 20. http://www.se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/specyfikacja-wymagan-dla-systemow-informatycznych We have just received permission to publish results of the project Guideliness for Developing SRS, realized in co-operation with the Poznan City Hall, which goal was to provide guideliness for development of software requirements specifications (especially when bid of tender procedure is involved). No publisher mochodek quality attributes requirements engineering use case diagram SRS use cases ieee830:1998 2010-03-25T11:23:00Z Blog Entry http://www.se.cs.put.poznan.pl/projects/consulting/um-srs Goal of this project, realized in co-operation with the Poznan City Hall, was to provide guidelines for development of software requirements specifications (especially when bid of tender procedure is involved). No publisher mochodek requirements engineering iso9126 use cases 2011-05-08T19:45:22Z Rich document http://www.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 publisher mochodek pattern use case diagram requirements engineering use cases uml 2010-04-07T19:35:00Z Blog Entry http://www.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 publisher mochodek requirements engineering use cases use case diagram uml 2010-01-24T09:11:47Z Blog Entry http://www.se.cs.put.poznan.pl/knowledge-base/software-engineering-blog/ucp The Use Case Points (UCP) method, proposed by Gustav Karner can be used to estimate effort early in the project life-cycle, with relatively low cost. It is based on two main inputs which are actors complexity, measured based on the interface actor uses to communicate with the system; and use-case complexity measured in the number of so-called transactions in use-case scenarios. Here, I would like to present you basic information about the original method proposed by Karner. No publisher mochodek effort estimation use case points metrics use cases use-case transaction 2010-09-01T10:12:30Z Blog Entry http://www.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 publisher mochodek requirements engineering use cases use case diagram uml 2009-12-22T09:54:15Z Blog Entry http://www.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 publisher mochodek requirements engineering use cases 2009-12-19T12:05:19Z Blog Entry http://www.se.cs.put.poznan.pl/knowledge-base/software-projects-database/use-cases-database-ucdb/use-cases-database-ucdb The goal of UCDB is to collect use-case-based requirements specification from real software projects. No publisher mochodek metrics benchmark use cases 2009-12-09T07:28:47Z Rich document http://www.se.cs.put.poznan.pl/knowledge-base/software-projects-database/use-cases-database-ucdb The goal of UCDB is to collect use-case-based requirements specification from real software projects. No publisher mochodek benchmark use cases 2009-11-05T11:38:12Z Folder http://www.se.cs.put.poznan.pl/knowledge-base/software-projects-database We are trying to collect data from real software projects for research and calibration of effort estimation methods. No publisher mochodek benchmark use cases 2009-11-05T11:37:49Z Folder http://www.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 publisher mochodek effort estimation use case points ttpoints requirements engineering use cases use-case transaction 2010-09-04T11:21:15Z Blog Entry http://www.se.cs.put.poznan.pl/publications/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 publisher mochodek requirements engineering uc workbench use cases 2009-09-09T06:54:37Z Inproceedings Reference http://www.se.cs.put.poznan.pl/publications/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 publisher mochodek metrics requirements engineering benchmark use cases 2011-12-28T11:22:07Z Inproceedings Reference http://www.se.cs.put.poznan.pl/publications/Olek-2008 This paper presents a language called ScreenSpec that can be used to specify screens at requirements elicitation phase. ScreenSpec was successfully applied in 8 real projects. It is very effective: average time needed to specify a screen is 2 minutes, and takes an hour to become proficient in using it. Visual representation generated from ScreenSpec can be attached to requirements specification (e.g. as adornments to use cases). No publisher mochodek prototyping requirements engineering use cases 2011-08-11T07:44:32Z Inproceedings Reference http://www.se.cs.put.poznan.pl/publications/Ciemniewska-2007BIS Use cases are a popular way of specifying functional requirements of computer-based systems. Each use case contains a sequence of steps which are described with a natural language. Use cases, as any other description of functional requirements, must go through a review process to check their quality. The problem is that such reviews are time consuming. Moreover, effectiveness of a review depends on quality of the submitted document - if a document contains many easy-to-detect defects, then reviewers tend to find those simple defects and they feel exempted from working hard to detect difficult defects. To solve the problem it is proposed to augment a requirements management tool with a detector that would find easy-to-detect defects automatically. No publisher mochodek use cases natural language processing 2009-08-09T19:29:57Z Inproceedings Reference