Relationship analysis : improving the systems analysis process

A significant aspect of systems analysis involves discovering and representing entities and their inter-relationships. Guidelines exist to identify entities but do not provide a rigorous and comprehensive process to explicitly capture the relationship structure of the problem domain. Whereas, other analysis techniques lightly address the relationship discovery process, Relationship Analysis is the only systematic, domain-independent analysis technique focusing exclusively on a domain\u27s relationship structure. The quality of design artifacts, such as class diagrams, and development time necessary to generate these artifacts can be improved by first representing the complete relationship structure of the problem domain. The Relationship Analysis Model is the first theory-based taxonomy to classify relationships. A rigorous evaluation was conducted, including a formal experiment comparing novice and experienced analysts with and without Relationship Analysis. It was shown that the Relationship Analysis Process based on the model does provide a fuller and richer systems analysis, resulting in improved quality of and reduced time in generating class diagrams. It also was shown that Relationship Analysis enables analysts of varying experience levels to achieve a similar level of quality of class diagrams. Relationship Analysis significantly enhances the systems analyst\u27s effectiveness, especially in the area of relationship discovery and documentation resulting in improved analysis and design artifacts

Multi-level requirement model and its implementation for medical device

Indiana University-Purdue University Indianapolis (IUPUI)Requirements determine the expectations for a new or modified product. Requirements engineering involves defining, documentation and maintenance of requirements. The rapid improving of technologies and changing of market needs require a shorter time to market and more diversified products. As an important and complex task in product development, it is a huge work to develop new requirements for each new product from scratch. The reusability of requirements data becomes more and more important. However, with the current “copy and paste” approach, engineers have to go through the entire set of requirements (sometimes even more than one set of requirements) to identify the ones which need to be reused or updated. It takes a lot of time and highly relies on the engineers’ experiences. Software tools can only make it easier to capture and locate the requirements, but won’t be able to solve the problem of effective reuse of the existing requirement data. The overall goal of this research is to develop a new model to improve the management of requirements and make the reuse and reconfiguration of existing requirements and requirement models more efficient. Considering the requirements data as an important part of the knowledge body of companies, we followed the knowledge categorization method to classify requirements into groups, which were called levels in the study, based on their changing frequency. There are four levels, the regulatory level, the product line level, the product level and the project level. The regulatory level is the most stable level. Requirements in this level were derived from government and industry regulations. The product line level contains the common requirements for a group of products, the product line. The third level, product level, refers to the specific requirements of the product. And the fourth and most dynamic level, the project level, is about the specific configurations of a product for a project. We chose auto-injector as the application to implement the model, since it is a relatively simple product, but its requirements cover many different categories. There are three major steps in our research approach for the project. The first is to develop requirements and classify them for our model. The development of requirements adopts the goal-oriented model to analyze and SysML, a system modeling language, to build requirements model. And the second step is to build requirements template, connecting the solution of the problem to the information system, standalone requirements management tool or information platform. This step is to find a way to realize the multi-level model in an information system. The final step is to implement the model. We chose two software tools for the implementation, Microsoft Office Excel, a commonly used tool for generating requirements documents, and Siemens PLM suite, Teamcenter, a world leading PLM platform with a requirement module. The results in the study include an auto-injector requirement set, a workflow for using the multi-level model, two requirements templates for implementation of the model in two different software tools, and two automatically generated requirement reports. Our model helps to define the changed part of requirements after analysis of the product change. It could avoid the pitfalls of the current way in reusing requirements. Based on the results from this study, we can draw the following conclusions. A practical multi-level requirements management model can be used for a medical device—the auto-injector; and the model can be implemented into different software tools to support reuse of existing requirement data in creating requirement models for new product development projects. Furthermore, the workflow and guideline to support the application and maintenance of the requirement model can be successful developed and implemented. Requirement documents/reports can be automatically generated through the software tool by following the workflow. And according to our assessment, the multi-level model can improve the reusability of requirements

Negotiation of software requirements in an asynchronous collaborative environment

The effect of task structure and negotiation sequence on collaborative software requirements negotiation is investigated. This work began with an extensive literature review that focused on current research in collaborative software engineering and, in particular, on the negotiation of software requirements and the requisite collaboration for the development of such requirements. A formal detailed experiment was then conducted to evaluate the effects of negotiation sequence and task structure in an asynchronous group meeting environment. The experiment tested the impact of these structures on groups negotiating the requirements for an emergency response information system. The results reported here show that these structures can have a positive impact on solution quality but a negative impact on process satisfaction, although following a negotiation sequence and task structure can help asynchronous groups come to agreement faster. Details of the experimental procedures, statistical analysis, and discussion of the results of the experiment are also presented, as are suggestions for improving this work and a plan for future research

Reducing Ambiguities in Customer Requirements Through Historical Rule-Based Knowledge in a Small Organization

During the elicitation process the requirements for a software application are obtained from the customer. Customers often do not know how to clearly express the requirements of the application to be built, causing requirements to be ambiguous. Many studies have been found to cover different characteristics of the requirements elicitation process including methods for reducing ambiguities in requirements. The methods and findings of these studies were found to be too general when it comes to the specific domain of the requirements and knowledge about the requirements. In addition, some studies did not take into consideration the level of expertise of those users performing the process. The focus of this study is to reduce ambiguities in customer requirements for a specific domain through the use of a historical rule-based knowledge and a scripted process. Using a case study scenario, this study explores how ambiguities in customer requirements can be reduced using knowledge about specific requirements for Web-based forms. The scripted process is a step-by-step procedure utilized to guide a novice developer in reducing the ambiguities in customer requirements. The proposed rule-based knowledge encompasses requirements of previously implemented Web-based applications. The results of this study intend to improve domain knowledge sharing between novice and expert developers and domain experts while reducing ambiguities in customer requirements. The existence of ambiguities in requirements and the lack of knowledge about the domain, between customers and the development team, provide the context in this qualitative case study. The outcome of this study demonstrates how ambiguities in requirements can be reduced and easily understood by the development team while lessening the communication gap between all people involved. The impact of this study is relatively associated with the effort and time that goes into understanding requirements and reducing ambiguities

Characterizing the Application of Design Ethnography Techniques to Improve Novice Human-Centered Design Processes.

Design is a central, distinguishing feature of engineering, requiring the development of technical solutions to societal problems. Successful design solutions must not only be technically sound, but also well-adapted to the context and culture in which they will be used. However, the most commonly used methods for eliciting and characterizing stakeholder preferences do not typically reveal critical stakeholder and contextual information. Through the studies described in this dissertation, I explore the use of design ethnography during front-end engineering design phases to capture both stakeholder preferences and contextual knowledge to inform engineering design decision making. Design ethnography is a set of primarily qualitative data collection and analysis techniques that have been adapted from the field of anthropology to augment the engineering design process. Studies from the fields of human-computer interaction and product development have demonstrated that design ethnography techniques are cost-effective and lead to more successful products. However, the design ethnography literature lacks critical understanding of the major barriers and factors that influence design ethnography success, methodologies for synthesizing and applying design ethnography data, best practices to engage with stakeholders, developmental trajectories of novice to expert skill acquisition, and case studies of how design ethnography has been implemented in diverse settings. The studies detailed in this dissertation employ a mixture of quantitative and qualitative research methods to address these gaps in the literature. Through this research, I have characterized novice design ethnography implementation strategies and identified internal and external factors that affect design ethnography execution; investigated correlations between information processing ability and the quality of product requirements developed; established a framework for evaluating and directing design ethnography stakeholder interviews; developed a case study within a global health design context; and interpreted the findings within a theoretically grounded model to represent novice to expert development. This body of work informs strategies and processes for engaging with stakeholders and understanding broader contexts in design work to improve design decision making within both design professional practice and engineering education.PhDMechanical EngineeringUniversity of Michigan, Horace H. Rackham School of Graduate Studieshttp://deepblue.lib.umich.edu/bitstream/2027.42/133391/1/imohedas_1.pd

Evaluation Framework for Software Security Requirements Engineering Tools

Tarkvaraarenduses on nõuded kui süsteemi vundament, mis vastutavad ka ebaõnnestumiste eest. Valed nõuded võivad viia tarkvara eripäradeni, mis tegelikult ei vasta spetsifikatsioonidele. Sel põhjusel peetakse nõuete koostamist kõige keerulisemaks ja olulisemaks sammuks tarkvaraarenduse elutsükli kõikide protsesside jooksul. Tänapäeval, kus küberrünnakud on \n\rtavalised, mängivad turvalisuse nõuded väga olulist rolli tarkvaraarenduse protsessis. On levimas uut tüüpi tööriistad, mille kasutamist peetakse kõige efektiivsemaks meetodiks turvalisusnõuete väljatöötamisel. Lisaks võimaldavad need tööriistad lahendada turvalisusega seotud küsimusi kasutajal endal, hoides märgatavalt kokku inseneride aega. Siiski on nende tööriistade \n\rareng alles algstaadiumis ning neid ei ole tarkvarainseneride poolt massiliselt kasutusele võetud. Põhjus on väga pikas uue tarkvara õppimise ja sellega kohanemise protsessis, mis põhjustab ajakadu arendusprotsessis ning lisab projektile kulusid. Projekti jaoks konkreetse tööriista valimisel võib tutvumine ja katsetamine võtta inseneridel hulgaliselt aega. Lisaks sellele võib struktureerimata valikuprotsess viia vale tööriista kasutuselevõtmisele, mis raiskab omakorda kõigi aega ja pingutusi. Selles uurimuses kavatseme me koostada struktureeritud lähenemise, mis aitab insenere turvaliste tööriistade valimisel. Protsessile kaasaaitamiseks saavad analüütikud ja arhitektid hinnata tarkvara omadusi, mida nad enda seisukohast olulisimateks peavad. Sellest lähtuvalt saavad nad valida kindlate tööriistade vahel ning teha parima valiku. \n\rAntud uurimustöös konstrueeritud lähenemisega on võimalik säästa aega, vaeva ja kulutusi. Uurimuse koostamise käigus uurime me tarkvaraarenduse turvaprotsesse, meetodeid ja tööriistu ning püüame luua raamistikku, mis oleks inseneridele turvalisusnõuete tööriistade hindamisel abiks.In software development requirements are considered as building blocks of software system, which also are considered to be responsible in event of failure. Bad requirements can lead to software features that are not to the specifications. For that reason requirement gathering process is considered as the most sensitive and complicated process among all software engineering lifecycle processes. In current age where cyber-attacks are common security requirements also comes into place and plays a very important role in software development process. In order to elicit security requirements new type of tools are begin to form a shape called security engineering tools which help in eliciting security requirements. That considered being the most efficient way of eliciting security requirements. Moreover these tools empower users with artifacts specifically to cater security needs, which save time and efforts for engineers in return. Nevertheless these tools are still at their infantry and are lacking mass adoption by software security engineers. Reason because these tools have steep learning curve which can add-up to development time and end up pushing more cost to the project. In order to decide which tool to select for a particular project require engineers to use these tools which in return will consume tremendous amount of time. Moreover using unstructured tool selection process can also leads to wrong tool selection which will be the waste of time and efforts. In this research work we are going to construct structured approach which will help engineers in security engineering tool selection process. In order to aid this process analysts and architects will be able to rate the features they want the most in a particular security engineering tool. In return from this process they will be able to choose between security engineering tools and select the best one. Finally using approach constructed in this research work will save time, efforts, and costs. In our approach we will analyze security engineering processes, methods and tools, to construct a framework that will help aid engineers in security engineering tool evaluation process