Video game development is a high-risk effort with low probability of success. The interactive nature of the resulting artifact increases production complexity, often doing so in ways that are unexpected. New methodologies are needed to address issues in this domain.<p> Video game development has two major phases: preproduction and production. During <i>preproduction</i>, the game designer and other members of the creative team create and capture a vision of the intended player experience in the game design document. The game design document tells the story and describes the game - it does not usually explicitly elaborate all of the details of the intended player experience, particularly with respect to how the player is intended to feel as the game progresses. Details of the intended experience tend to be communicated verbally, on an as-needed basis during iterations of the production effort.<p> During <i>production</i>, the software and media development teams attempt to realize the preproduction vision in a game artifact. However, the game design document is not traditionally intended to capture production-ready requirements, particularly for software development. As a result, there is a communications chasm between preproduction and production efforts that can lead to production issues such as excessive reliance on direct communication with the game designer, difficulty scoping project elements, and difficulty in determining reasonably accurate effort estimates.<p> We posit that defining and capturing the intended player experience in a manner that is influenced and informed by established requirements engineering principles and techniques will help cross the communications chasm between preproduction and production. The proposed experience requirements methodology is a novel contribution composed of:<p> <ol> <li>a model for the elements that compose experience requirements,</li> <li>a framework that provides guidance for expressing experience requirements, and</li> <li>an exemplary process for the elicitation, capture, and negotiation of experience requirements.</li> <ol><p> Experience requirements capture the designer' s intent for the user experience; they represent user experience goals for the artifact and constraints upon the implementation and are not expected to be formal in the mathematical sense. Experience requirements are evolutionary in intent - they incrementally enhance and extend existing practices in a relatively lightweight manner using language and representations that are intended to be mutually acceptable to preproduction and to production.

Although online social media have achieved spectacular success in some instances, the design of such systems remains an art. In some specialized areas, such as online deliberation systems for participatory democracy, experiences from many projects have been reported in the research literature. Designers can benefit from knowledge accumulated from these experiences. However, the knowledge is dispersed and not organized for ready access by practicing professionals. This thesis proposes a framework for structuring and codifying design knowledge from published studies to help designers make design choices that will attain design objectives.

Although online social media have achieved spectacular success in some instances, the design of such systems remains an art. In some specialized areas, such as online deliberation systems for participatory democracy, experiences from many projects have been reported in the research literature. Designers can benefit from knowledge accumulated from these experiences. However, the knowledge is dispersed and not organized for ready access by practicing professionals. This thesis proposes a framework for structuring and codifying design knowledge from published studies to help designers make design choices that will attain design objectives.

The main goal of any object-oriented analysis (OOA) method is to produce a model that aids in understanding and communicating knowledge about a modeled domain. A higher degree of similarity among independently produced domain models provides an indication of how well the domain was understood by the different analysts, i. e. , more similar models indicate a closer and a more common understanding of a domain. A common understanding is of critical importance for effective knowledge communication and sharing. <br /><br /> The core of any OOA method is discovering and understanding concepts and their relationships in a domain. The main artifact produced by an OOA method is a domain model of the domain. A domain model often serves as the main source of design concepts during objectoriented design (OOD). This thesis evaluates two OOA methods by comparing the degree of similarity of the resulting domain models. <br /><br /> In particular, this work compares the semantic similarity of domain models extracted from use cases by <ol> <li>specification of sequence diagrams and then domain models, and </li> <li>specification of unified use case statecharts and then domain models. </li> </ol> The thesis makes case studies out of the application of the first method to 31 instances of large Voice-over-IP (VoIP) system and its information management system (IMS) and to 3 small elevator systems, and out of the application of the second method to 46 instances of the same large VoIP system and its IMS and to 12 instances of a medium-sized elevator system. <br /><br /> From an analysis of data from these case studies, the thesis concludes that there is an increase of 10% in the semantic similarity of domain models produced using the second method, but at the cost of less than or equal to 25% more analysis time.

The main goal of any object-oriented analysis (OOA) method is to produce a model that aids in understanding and communicating knowledge about a modeled domain. A higher degree of similarity among independently produced domain models provides an indication of how well the domain was understood by the different analysts, i. e. , more similar models indicate a closer and a more common understanding of a domain. A common understanding is of critical importance for effective knowledge communication and sharing. <br /><br /> The core of any OOA method is discovering and understanding concepts and their relationships in a domain. The main artifact produced by an OOA method is a domain model of the domain. A domain model often serves as the main source of design concepts during objectoriented design (OOD). This thesis evaluates two OOA methods by comparing the degree of similarity of the resulting domain models. <br /><br /> In particular, this work compares the semantic similarity of domain models extracted from use cases by <ol> <li>specification of sequence diagrams and then domain models, and </li> <li>specification of unified use case statecharts and then domain models. </li> </ol> The thesis makes case studies out of the application of the first method to 31 instances of large Voice-over-IP (VoIP) system and its information management system (IMS) and to 3 small elevator systems, and out of the application of the second method to 46 instances of the same large VoIP system and its IMS and to 12 instances of a medium-sized elevator system. <br /><br /> From an analysis of data from these case studies, the thesis concludes that there is an increase of 10% in the semantic similarity of domain models produced using the second method, but at the cost of less than or equal to 25% more analysis time.

Video game development is a high-risk effort with low probability of success. The interactive nature of the resulting artifact increases production complexity, often doing so in ways that are unexpected. New methodologies are needed to address issues in this domain.<p> Video game development has two major phases: preproduction and production. During <i>preproduction</i>, the game designer and other members of the creative team create and capture a vision of the intended player experience in the game design document. The game design document tells the story and describes the game - it does not usually explicitly elaborate all of the details of the intended player experience, particularly with respect to how the player is intended to feel as the game progresses. Details of the intended experience tend to be communicated verbally, on an as-needed basis during iterations of the production effort.<p> During <i>production</i>, the software and media development teams attempt to realize the preproduction vision in a game artifact. However, the game design document is not traditionally intended to capture production-ready requirements, particularly for software development. As a result, there is a communications chasm between preproduction and production efforts that can lead to production issues such as excessive reliance on direct communication with the game designer, difficulty scoping project elements, and difficulty in determining reasonably accurate effort estimates.<p> We posit that defining and capturing the intended player experience in a manner that is influenced and informed by established requirements engineering principles and techniques will help cross the communications chasm between preproduction and production. The proposed experience requirements methodology is a novel contribution composed of:<p> <ol> <li>a model for the elements that compose experience requirements,</li> <li>a framework that provides guidance for expressing experience requirements, and</li> <li>an exemplary process for the elicitation, capture, and negotiation of experience requirements.</li> <ol><p> Experience requirements capture the designer' s intent for the user experience; they represent user experience goals for the artifact and constraints upon the implementation and are not expected to be formal in the mathematical sense. Experience requirements are evolutionary in intent - they incrementally enhance and extend existing practices in a relatively lightweight manner using language and representations that are intended to be mutually acceptable to preproduction and to production.

<p>Utvecklingen av informationssystem utförs vanligen med hjälp av en systemutvecklingsmodell där kravhanteringsaktivitetens (Requirements Engineering – RE-processen) syfte är att samla in och bearbeta kundens alla krav på systemet. Den slutliga produkten av RE-processen är en kravspecifikation där alla kraven gällande exempelvis systemets funktionalitet, syfte etc skall specificeras.</p><p>Det är inte alltid självklart vilken information som en kravspecifikation bör innehålla då detta dokument kan för både kunden och leverantören ses som ett kvitto på vad som skall utvecklas och hur det skall gå till. Dokumentet skall nämligen fungera som ett underlag för de så kallade implementations- och designaktiviteterna i systemutvecklingsarbetet samt fungera som ett underlag för diskussion och kontrakt mellan leverantör och kund gällande utvecklingen av informationssystemet. Kravspecifikationen bör därför innehålla komplett och förståelig information så att detta dokument uppfyller sina syften. Därmed är det inte enkelt att veta vilken information som en kravspecifikation bör innehålla för att detta dokument skall uppfylla ovannämnda egenskaper. Då kravspecifikationen skall upprättas kan ett ramverk eller en standard tillämpas som förespråkar att viss information skall ingå.</p><p>Det ramverk som är upprättat i detta examensarbete innehåller den information som jag anser bör ingå i en kravspecifikation. Utifrån detta ramverk finns det viss information som jag anser att en kravspecifikation bör innehålla just ur kontraktsynpunkt. Denna information är följande:</p><p>· Informationssystemets funktioner</p><p>· Informationssystemets funktionella egenskaper</p><p>· Informationssystemets generella egenskaper</p><p>· Utbildning</p><p>· Dokumentation</p><p>· Leveransdatum</p>

<p>I dagens samhälle spelar informationssystem en viktig roll i de flesta företag och organisationer. Informationssystemets uppgift är att tillgodose och hjälpa användarna med information och informationshantering samt att leda till en effektivisering.</p><p>Arbetet med att utveckla databaserade informationssystem är problematiskt och systemutvecklingsprojekt överstiger ofta budget både vad gäller tid och pengar. Återkommande problem är att systemen inte gör vad användaren vill samt att systemen inte utnyttjas till full kapacitet. Svårigheten med kravhanteringen är något som anses vara en orsak till misslyckandena.</p><p>Den viktigaste informationskällan för systemutvecklarna då det gäller att ta reda på systemkraven är användarna. Då användarna spelar en viktig roll i kravhanteringen, vilken i sin tur spelar en viktig roll i systemutvecklingsprocessen, är detta ett intressant problemområde.</p><p>Denna rapports fokus ligger på hur användarna ser på kravhanteringsprocessen. Syftet med rapporten är att ur ett användarperspektiv utvärdera användarmedverkan i systemutvecklingsprocessens samt att försöka finna om det finns ett samband mellan användares erfarenheter ifrån systemutvecklingsprocessen och deras åsikter kring det färdiga systemet.</p>

Zugl.: Erlangen, Nürnberg, Univ., Diss., 2006 / Hergestellt on demand

The domain of this research are CASE tools, designated for requirements engineering, which are able to generate computerized information system prototypes. The main goal of this project is to design software, which would enable to generate an IS prototype from requirements specification, created re specification method, suggested by the Information Systems department. The software is a part of a CASE tool, designed by the IS department. The CASE tool is designated for creating requirements specification and the software will provide additional functionality to it. The opportunities of computerized IS prototyping using Oracle Designer, Visual FoxPro and MS Access were analyzed. In case of Oracle Designer, in order to create a computerized IS prototype we have to go through the whole design stage. In case of DBMS Visual FoxPro and MS Access we must have a database designed. And the software for generating computerized IS prototype enables you to generate a system prototype at an early design stage and without having the system project.