In contemporary software development, an emergent understanding of the problem domain and envisioned goals forms the basis of designing, testing and development activities. Lack of a common understanding of the domain can result in costly rework or client dissatisfaction. Research shows that the development of shared understanding in this context is a complex and error-prone process and there is room for improvement. Is this because practitioners are not following suggested practice from literature? Or are the actual barriers to shared understanding not being addressed by current tools and techniques? Is the development of shared domain understanding even viewed as problematic (or even important) by practitioners? These are some questions that need to be investigated in order to effectively design process improvements and tool support in this area, yet there is little information related to this. This study takes a multi-case study approach, which incorporate semi-structured interviews with representative from ten small-to-medium organisations. This study focuses on the vendor’s perspective and includes a mix of application domains. Result of the interviews is analysed to discover themes and patterns related to an analysis framework constructed from the literature review. The findings indicate that vendors perceive the process of developing shared application-domain understanding with their clients as being both problematic and important to a successful implementation. Twelve barriers have been identified from the analysis. The results also confirm that the process of sharing understanding development is generally perceived as being evolutionary and collaborative. This process is described by most interviewees comprises iterative phases of elicitation, confirmation and refinement of the understanding. A definite preference for face-to-face interaction is evident at regular times throughout development, particularly in early stages, although the importance of ad-hoc communications by phone or email, as domain knowledge needs arise, is also emphasised. Access to cooperative domain-expert throughout development is generally seen as a critical success factor. Several companies report using in-house domain-expert as client “proxies” in this regard. There is a mix of attitudes apparent regarding the direct communications of developers with client stakeholders. This ranged from insisting that developers are involved from initial elicitation and “kick-off” meetings, to “shielding” developers almost entirely from client. In terms of representations of understanding, participants relate natural-language, screen-shots, mock-ups, prototypes and product-demonstrations as the most useful artefacts for sharing and confirming understanding of the problem domain. They emphasise the importance of flexibility and client familiarity with the representations. In general, there is no clear separation between problem and solution spaces evident when the interviewees discussed representations of understanding, and the preference seems to be for concrete rather than abstract representations. In conclusion, comparisons between the findings and literature generally confirm contemporary thinking regarding domain knowledge sharing, although a number of barriers were given particular emphasis in this field study. The use of computer-based tool support is not widespread and the need to improve the domain knowledge sharing process and tool support in practice is widely acknowledged by the participants in this investigation. This study has identified some fruitful areas of research in this regard.

<p>The background to the study was Unified Communications (UC), defined as Communications integrated to optimize business processes. A case study design is used to develop a LoFi-prototype. The prototype investigateswhat components an integrated communication solution should provide,for the people in radiology. The design was inspired by consumer products likeSkype. In these consumer products were functionality and look studied. The reason for integrate it into Sectra MEI, was that Sectra believed the system’s features could be even more useful, when used together with a communication solution. The prototype is tested on users (usability tested). To bundle the growing pile of requirements in the design process was a requirement specification produced.</p>

This thesis presents a preliminary goal oriented modeling of situation awareness in a command and control system. Tropos, an agent oriented software development methodology, has been used for modeling. Use of Tropos allows us to represent, at the knowledge level, the Command and Control actors along with their goals and interdependencies. Through refinement we aim to derive an architectural design for the Situation Awareness component of an Air Defense Command and Control system. This work suggests that goal oriented methodologies can be successfully used in the modeling of the complex systems at the requirement analysis phase. By analyzing dependencies between Command and Control entities, it should be possible to improve the modularity of the Command and Control system architecture.

Today, software ecosystems have become transparent, allowing users to submit issue reports and new feature requests to the development team. The more permeable boundaries of ecosystems provide an open culture paradigm where stakeholders, customers, developers and other user groups have the access to participate during all phases of requirement development. One example of this open culture in software ecosystems is found in work item discussions, which are aimed to improve how requirements are elicited, analyzed and validated. In this thesis, we investigate who participates in requirements discussions, identifying and focusing on emergent contributors; discussants that are not officially part of the development team or required to participate, but contribute to work item discussions. We report form a case study of online requirement discussion in IBM’s collaborative lifecycle management. We find that external contributors emerge frequently during discussions and that they mediate the clarification of requirements. Our results indicate that it is important for emergent contributors to be involved early in the requirements process, otherwise there is a negative effect on the work items’ progress. We discuss the implications of our findings for both practitioners and researchers with suggestions for future studies. / Graduate / 0984 / 0291 / 0790 / aminah.yussuf@gmail.com

In the early stage of building a new informational system requirement engineering involves all the processes related to the requirement system and research of problems emerged during this process. In this stage the requirements specification of corresponding information system are built. Many different notations serve for this purpose, selection of which is dependant on available resources and project goals. Requirements specification must be of good quality. It is evaluated by characteristics of quality. Specifications could be analyzed and improved by using various tools including CASE tools. The specification is developed and its quality is improved by making analysis of requirements. Well done specification is basis for creating high leveled functionality system.

Problems of requirements which are identified in the earlier phase of a software development project can deeply affect the success of the project. Thus studies which aim to decrease these problems are crucial. Automation is foreseen to be one of the possible solutions for decreasing or removing some of the problems originating from requirements. This study focuses on the development and implementation of an automated tool that will generate requirements in natural language from business process models. In this study, The benefits of the tool are discussed, and the tool is compared with other software requirement s related tools with respect to their functionality. The developed tool has been tested within a large military project and the results of using the tool are presented.

In contemporary software development, an emergent understanding of the problem domain and envisioned goals forms the basis of designing, testing and development activities. Lack of a common understanding of the domain can result in costly rework or client dissatisfaction. Research shows that the development of shared understanding in this context is a complex and error-prone process and there is room for improvement. Is this because practitioners are not following suggested practice from literature? Or are the actual barriers to shared understanding not being addressed by current tools and techniques? Is the development of shared domain understanding even viewed as problematic (or even important) by practitioners? These are some questions that need to be investigated in order to effectively design process improvements and tool support in this area, yet there is little information related to this. This study takes a multi-case study approach, which incorporate semi-structured interviews with representative from ten small-to-medium organisations. This study focuses on the vendor’s perspective and includes a mix of application domains. Result of the interviews is analysed to discover themes and patterns related to an analysis framework constructed from the literature review. The findings indicate that vendors perceive the process of developing shared application-domain understanding with their clients as being both problematic and important to a successful implementation. Twelve barriers have been identified from the analysis. The results also confirm that the process of sharing understanding development is generally perceived as being evolutionary and collaborative. This process is described by most interviewees comprises iterative phases of elicitation, confirmation and refinement of the understanding. A definite preference for face-to-face interaction is evident at regular times throughout development, particularly in early stages, although the importance of ad-hoc communications by phone or email, as domain knowledge needs arise, is also emphasised. Access to cooperative domain-expert throughout development is generally seen as a critical success factor. Several companies report using in-house domain-expert as client “proxies” in this regard. There is a mix of attitudes apparent regarding the direct communications of developers with client stakeholders. This ranged from insisting that developers are involved from initial elicitation and “kick-off” meetings, to “shielding” developers almost entirely from client. In terms of representations of understanding, participants relate natural-language, screen-shots, mock-ups, prototypes and product-demonstrations as the most useful artefacts for sharing and confirming understanding of the problem domain. They emphasise the importance of flexibility and client familiarity with the representations. In general, there is no clear separation between problem and solution spaces evident when the interviewees discussed representations of understanding, and the preference seems to be for concrete rather than abstract representations. In conclusion, comparisons between the findings and literature generally confirm contemporary thinking regarding domain knowledge sharing, although a number of barriers were given particular emphasis in this field study. The use of computer-based tool support is not widespread and the need to improve the domain knowledge sharing process and tool support in practice is widely acknowledged by the participants in this investigation. This study has identified some fruitful areas of research in this regard.

It is reported that the market-driven product development is becoming common in the software industry. There are two challenges in the market-driven product development: time-to-market and meeting customers’ requirements. A rapid software development process is regarded as a good way to solve those two challenges. Streamline development process (SLDP) is aligned with a rapid software development process, which is an in-house development process of Ericsson AB. In this study, seven completed projects from the streamline development process were investigated. The correlations between requirement attributes and process attributes were identified and quantified in the SLDP. Nine hypotheses were assumed. Four hypotheses were derived from the correlations from the other software development processes, and the other five hypotheses were derived from new requirement attributes and process attributes in SLDP. Two statistical software applications were used in the hypotheses testing. The results of those hypotheses showed that too much time spent in the early phase of streamline development would not reduce the time to market. A SLDP measurement program contains the measurements of requirement attributes and process attributes. This measurement program was mainly composed of four core attributes (size, effort, schedule, and fault), the requirement volatility, the completeness, the resource overrun, and the estimation accuracy. The results of the SLDP measurement program reflected four challenges in the SLDP: the requirement engineering process, the release planning, the estimation accuracy at each development phase, and the quality of the documentation. At last, based on those four challenges (the requirement engineering process, the release planning, the estimation accuracy at each development phase, and the quality of the documentation) and the defined correlations between requirement attributes and process attributes in the SLDP, the improvement opportunities were proposed for the SLDP.

Context. Requirements changes are unavoidable in any software project. Requirements change over time as software projects progress, and involved stakeholders (mainly customers) and developers gain better understanding of the final product. Additionally, time and budget constraints prevent implementing all candidate requirements and force project management to select a subset of requirements that are prioritized more important than the others so as to be implemented. As a result, some requirements become cancelled and deleted during the elicitation and specification phase while other requirements are considered not important during the prioritization phase. A common scenario in this situation is to leave the excluded requirements for being considered in the next release. The constant leaving of the excluded requirements for the next release may simply render them obsolete.

The background to the study was Unified Communications (UC), defined as Communications integrated to optimize business processes. A case study design is used to develop a LoFi-prototype. The prototype investigateswhat components an integrated communication solution should provide,for the people in radiology. The design was inspired by consumer products likeSkype. In these consumer products were functionality and look studied. The reason for integrate it into Sectra MEI, was that Sectra believed the system’s features could be even more useful, when used together with a communication solution. The prototype is tested on users (usability tested). To bundle the growing pile of requirements in the design process was a requirement specification produced.