From requirements negotiation to software architecture decisions

Architecture design and requirements negotiations are conceptually tightly related but often performed separately in real-world software development projects. As our prior case studies have revealed, this separation causes uncertainty in requirements negotiation that hinders progress, limits the success of architecture design, and often leads to wasted effort and substantial re-work later in the development life-cycle. Explicit requirements elicitation and negotiation is needed to be able to appropriately consider and evaluate architecture alternatives and the architecture alternatives need be understood during requirements negotiation. This paper propose the WinCBAM framework, extending an architecture design method, called cost benefit analysis method (CBAM) framework to include an explicit requirements negotiation component based on the WinWin methodology. We then provide a retrospective case study that demonstrates the use of the WinCBAM. We show that the integrated method is substantially more powerful than the WinWin and CBAM methods performed separately. The integrated method can assist stakeholders to elicit, explore, evaluate, negotiate, and agree upon software architecture alternatives based on each of their requirement Win conditions. By understanding the architectural implication of requirements they can be negotiated more successfully: potential requirements conflicts can be discovered or alleviated relatively early in the development life-cycle.     

可信软件非功能需求可满足性经济学方法分析

针对软件可信性的重要性以及非功能需求的策略选取对软件可信性的影响,提出了一种在早期需求工程阶段将用于辅助决策的经济学和需求工程相结合的方法,并提出了可信软件非功能需求可满足性的策略选取框架,以辅助策略选取。首先,对功能需求及经济学方法概念进行了定义和转换,例如,将软件开发过程中的非功能需求看作经济学生产过程中的生产要素、软件的利益相关者看作生产过程中的生产者等;并定义了非功能需求分解模型。在此基础上,基于模糊集合论和信息熵对软件非功能需求进行模糊排序从而获取利益相关者的关键非功能需求,并利用经济学中生产过程的相关方法计算使用策略的可信性效益,辅助策略的选取。以移动基础维护管理平台为例,使用提出的方法,说明了所提方法的可行性。     

Commitment analysis to operationalize software requirements from privacy policies

Online privacy policies describe organizations’ privacy practices for collecting, storing, using, and protecting consumers’ personal information. Users need to understand these policies in order to know how their personal information is being collected, stored, used, and protected. Organizations need to ensure that the commitments they express in their privacy policies reflect their actual business practices, especially in the United States where the Federal Trade Commission regulates fair business practices. Requirements engineers need to understand the privacy policies to know the privacy practices with which the software must comply and to ensure that the commitments expressed in these privacy policies are incorporated into the software requirements. In this paper, we present a methodology for obtaining requirements from privacy policies based on our theory of commitments, privileges, and rights, which was developed through a grounded theory approach. This methodology was developed from a case study in which we derived software requirements from seventeen healthcare privacy policies. We found that legal-based approaches do not provide sufficient coverage of privacy requirements because privacy policies focus primarily on procedural practices rather than legal practices.     

Integrated safety analysis of requirements specifications

This paper describes an integrated approach to safety analysis of software requirements and demonstrates the feasibility and utility of applying the individual techniques and the integrated approach on the requirements specification of a guidance system for a high-speed civil transport being developed at NASA Ames. Each analysis found different types of errors in the specification; thus together the techniques provided a more comprehensive safety analysis than any individual technique. We also discovered that the more the analyst knew about the application and the model, the more successful they were in finding errors. Our findings imply that the most effective safety-analysis tools will assist rather than replace the analyst. A shorter version of this paper appeared in the Proceedings of the 3rd International Symposium on Requirements Engineering, Annapolis, Maryland, January 1997. The research described has been partly funded by NASA/Langley Grant NAG-1-1495, NSF Grant CCR-9396181, and the California PATH Program of the University of California     

安全苛求软件需求规格中的安全特性验证方法

针对自然语言描述的安全苛求软件需求规格中安全特性不准确、不一致等问题,提出一种基于UMLsec安全特性验证方法。该方法在UML需求模型类图和顺序图的基础上,为核心类的安全特性自定义构造型、标记和约束,完成UMLsec模型构建;之后,使用设计实现的UMLsec支持工具对安全特性进行自动验证。实验结果表明,该方法能准确描述安全苛求软件需求规格的安全特性,同时可以自动验证安全特性是否满足安全需求。     

Obsolete software requirements

ContextCoping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in requirements obsolescence even before project completion.ObjectiveAlthough the obsolete requirements phenomenon and the implications of not addressing them are known, there is a lack of empirical research dedicated to understanding the nature of obsolete software requirements and their role in requirements management.MethodIn this paper, we report results from an empirical investigation with 219 respondents aimed at investigating the phenomenon of obsolete software requirements.ResultsOur results contain, but are not limited to, defining the phenomenon of obsolete software requirements, investigating how they are handled in industry today and their potential impact.ConclusionWe conclude that obsolete software requirements constitute a significant challenge for companies developing software intensive products, in particular in large projects, and that companies rarely have processes for handling obsolete software requirements. Further, our results call for future research in creating automated methods for obsolete software requirements identification and management, methods that could enable efficient obsolete software requirements management in large projects.     

Investigating dependencies in software requirements for change propagation analysis

ContextThe dependencies between individual requirements have an important influence on software engineering activities e.g., project planning, architecture design, and change impact analysis. Although dozens of requirement dependency types were suggested in the literature from different points of interest, there still lacks an evaluation of the applicability of these dependency types in requirements engineering.ObjectiveUnderstanding the effect of these requirement dependencies to software engineering activities is useful but not trivial. In this study, we aimed to first investigate whether the existing dependency types are useful in practise, in particular for change propagation analysis, and then suggest improvements for dependency classification and definition.MethodWe conducted a case study that evaluated the usefulness and applicability of two well-known generic dependency models covering 25 dependency types. The case study was conducted in a real-world industry project with three participants who offered different perspectives.ResultsOur initial evaluation found that there exist a number of overlapping and/or ambiguous dependency types among the current models; five dependency types are particularly useful in change propagation analysis; and practitioners with different backgrounds possess various viewpoints on change propagation. To improve the state-of-the-art, a new dependency model is proposed to tackle the problems identified from the case study and the related literature. The new model classifies dependencies into intrinsic and additional dependencies on the top level, and suggests nine dependency types with precise definitions as its initial set.ConclusionsOur case study provides insights into requirement dependencies and their effects on change propagation analysis for both research and practise. The resulting new dependency model needs further evaluation and improvement.     

Analyzing evolution of variability in a software product line: From contexts and requirements to features

Context

In the long run, features of a software product line (SPL) evolve with respect to changes in stakeholder requirements and system contexts. Neither domain engineering nor requirements engineering handles such co-evolution of requirements and contexts explicitly, making it especially hard to reason about the impact of co-changes in complex scenarios.

Objective

In this paper, we propose a problem-oriented and value-based analysis method for variability evolution analysis. The method takes into account both kinds of changes (requirements and contexts) during the life of an evolving software product line.

Method

The proposed method extends the core requirements engineering ontology with the notions to represent variability-intensive problem decomposition and evolution. On the basis of problemorientation, the analysis method identifies candidate changes, detects influenced features, and evaluates their contributions to the value of the SPL.

Results and Conclusion

The process of applying the analysis method is illustrated using a concrete case study of an evolving enterprise software system, which has confirmed that tracing back to requirements and contextual changes is an effective way to understand the evolution of variability in the software product line.     

Means-ends and whole-part traceability analysis of safety requirements

Safety is a system property, hence the high-level safety requirements are incorporated into the implementation of system components. In this paper, we propose an optimized traceability analysis method which is based on the means-ends and whole-part concept of the approach for cognitive systems engineering to trace these safety requirements. A system consists of hardware, software, and humans according to a whole-part decomposition. The safety requirements of a system and its components are enforced or implemented through a means-ends lifecycle. To provide evidence of the safety of a system, the means-ends and whole-part traceability analysis method will optimize the creation of safety evidence from the safety requirements, safety analysis results, and other system artifacts produced through a lifecycle. These sources of safety evidence have a causal (cause-consequence) relationship between each other. The failure mode and effect analysis (FMEA), the hazard and operability analysis (HAZOP), and the fault tree analysis (FTA) techniques are generally used for safety analysis of systems and their components. These techniques cover the causal relations in a safety analysis. The causal relationships in the proposed method make it possible to trace the safety requirements through the safety analysis results and system artifacts. We present the proposed approach with an example, and described the usage of TRACE and NuSRS tools to apply the approach.     

From conceptual modelling to requirements engineering

Conceptual modelling is situated in the broader view of information systems requirements engineering. Requirements Engineering (RE) explores the objectives of different stakeholders and the activities carried out by them to meet these objectives in order to derive purposeful system requirements and therefore lead to better quality systems, i.e., systems that meet the requirements of their users. Thus RE product models use concepts for modelling these instead of concepts like data, process, events, etc., used in conceptual models. Since the former are more stable than the latter, requirements engineering manages change better. The paper gives the rationale for extending traditional conceptual models and introduces some RE product models. Furthermore, in contrast to conceptual modelling, requirements engineering lays great stress on the engineering process employed. The paper introduces some RE process models and considers their effect on tool support. This revised version was published online in June 2006 with corrections to the Cover Date.     

Impediments to requirements engineering during global software development

Developing software when team members are located in widely distributed geographic locations poses many challenges for developers, particularly during the requirements engineering (RE) phase. Using a case study of a large software development project with users located in the UK and software developers from an international software house based in New Zealand, the paper argues that while global RE using electronic communication media may be desirable in achieving economy of resources, social and cultural aspects of RE need to be considered so that lasting relationships with clients may be formed, and RE activities achieved. The main impediments to the process of RE during global software development are communication resulting from differences in shared meanings and context associated with the following: distribution of the clients and the development team; distribution of the development team; cultural differences between the clients and the development team; and cultural differences among the development team.     

软件项目需求波动风险分析及对策

从需求波动风险的定义出发,总结了需求波动形成的原因和对软件项目的影响,列举了一些代表性的风险分析和评估方法。最后提出了基于面向对象方法的系统需求工程的分析设计思路。     

计算机联网软件的制式安全评价分析

随着信息时代的到来,信息量的急剧增加,我们的生活越来越离不开计算机网络,人们对计算机网络的依赖度越来越高,很多工作的进行都离不开计算机网络,很多的信息和数据都存储在计算机中,计算机使我们的工作量和工作难度大大降低,但计算机网络是一把双刃剑,带给我们便利的同时,也给我们带来了很多的风险,这些风险主要包括计算机病毒带来的风险,计算机设备安装带来的风险,网络数据库带来的风险和实际操作失误带来的风险。这些风险一旦发生,将会造成无法预测的后果,给计算机用户带来损失。因此,对计算机联网软件的制式安全评价分析就显得尤为重要。     

Acquiring COTS software selection requirements

Commercial off the shelf software can save development time and money if you can find a package that meets your customer's needs. The authors propose a model for matching COTS product features with user requirements. To support requirements acquisition for selecting commercial off the shelf products, we propose a method we used recently for selecting a complex COTS software system that had to comply with over 130 customer requirements. The lessons we learned from that experience refined our design of PORE (procurement oriented requirements engineering), a template based method for requirements acquisition. We report 11 of these lessons, with particular focus on the typical problems that arose and solutions to avoid them in the future. These solutions, we believe, extend state of the art requirements acquisition techniques to the component based software engineering process     

From knowledge based software engineering to knowware based software engineering

The first part of this paper reviews our efforts on knowledge-based software engineering, namely PROMIS, started from 1990s. The key point of PROMIS is to generate applications automatically based on domain knowledge as well as software knowledge. That is featured by separating the development of domain knowledge from the development of software. But in PROMIS, we did not find an appropriate representation for the domain knowledge. Fortunately, in our recent work, we found such a carrier for knowledge modules, i.e. knowware. Knowware is a commercialized form of domain knowledge. This paper briefly introduces the basic definitions of knowware, knowledge middleware and knowware engineering. Three life circle models of knowware engineering and the design of corresponding knowware implementations are given. Finally we discuss application system automatic generation and domain knowledge modeling on the J2EE platform, which combines the techniques of PROMIS, knowware and J2EE, and the development and deployment framework, i.e. PROMIS/KW＊＊.     

Deriving engineering software from requirements

With the advent of intelligent computer aided design systems, companies such as Boeing are embarking on an era in which core competitive engineering knowledge and design rationale is being encoded in software systems. The promise of this technology is that this knowledge can be leveraged across many different designs, product families, and even different uses (e.g., generative process planning for manufacturing). The current state of the practice attempts to achieve this goal through the reuse of software components. A fundamental problem with this approach to knowledge sharing and reuse is that what we are trying to reuse is software—the end artifact in a long and complicated process that goes from requirement specifications, through a process of design, to implementations. Knowledge sharing and reuse can not easily and uniformly occur at the software level. So what can be done as an alternative? This paper describes a theory, methodology, language, and tool for the semi-automatic development and maintenance of engineering software from requirement specifications. In essence, this paradigm for software development and maintenance is one that explicitly captures requirement specifications, designs, implementations, and the refinement processes that lead from requirements all the way down to software. By recording this entire refinement history, we stand a better chance of leveraging knowledge for different uses.     

Quantifying requirements elaboration to improve early software cost estimation

This paper describes an empirical study undertaken to investigate the quantitative aspects of the phenomenon of requirements elaboration which deals with transformation of high-level goals into low-level requirements. Prior knowledge of the magnitude of requirements elaboration is instrumental in developing early estimates of a project’s cost and schedule. This study examines the data on two different types of goals and requirements - capability and level of service (LOS) - of 20 real-client, graduate-student, team projects done at USC. Metrics for data collection and analyses are described along with the utility of results they produce. Besides revealing a marked difference between the elaboration of capability goals and the elaboration of LOS goals, these results provide some initial relationships between the nature of projects and their ratios of elaboration of capability goals into capability or functional requirements.     

Monitoring and diagnosing software requirements

We propose a framework adapted from Artificial Intelligence theories of action and diagnosis for monitoring and diagnosing failures of software requirements. Software requirements are specified using goal models where they are associated with preconditions and postconditions. The monitoring component generates log data that contains the truth values of specified pre/post-conditions, as well as system action executions. Such data can be generated at different levels of granularity, depending on diagnostic feedback. The diagnostic component diagnoses the denial of requirements using the log data, and identifies problematic components. To support diagnostic reasoning, we transform the diagnostic problem into a propositional satisfiability (SAT) problem that can be solved by existing SAT solvers. The framework returns sound and complete diagnoses accounting for observed aberrant system behaviors. Our solution is illustrated with two medium-sized publicly available case studies: a Web-based email client and an ATM simulation. Our experimental results demonstrate the scalability of our approach.     

The impact of requirements analysis upon user satisfaction with packaged software

This article explores the relationship between carrying out requirements analysis activities and ultimate satisfaction with the software acquired. The requirements analysis activities performed by a sample of twelve organizations which acquired a particular general accounting package are evaluated. The satisfaction with the package is determined and analysis performed to establish the relationships between requirements analysis and user satisfaction. It is determined that for the particular population sampled there is little relationship. Possible reasons for this counter-intuitive finding are advanced.     

Effectiveness and performance analysis of model-oriented security requirements engineering to elicit security requirements: a systematic solution for developing secure software systems

Software systems are becoming more and more critical in every domain of human society. These systems are used not only by corporates and governments, but also by individuals and across networks of organizations. The wide use of software systems has resulted in the need to contain a large amount of critical information and processes, which certainly need to remain secure. As a consequence, it is important to ensure that the systems are secure by considering security requirements at the early phases of software development life cycle. In this paper, we propose to consider security requirements as functional requirements and apply model-oriented security requirements engineering framework as a systematic solution to elicit security requirements for e-governance software systems. As the result, high level of security can be achieved by more coverage of assets and threats, and identifying more traces of vulnerabilities in the early stages of requirements engineering. This in turn will help to elicit effective security requirements as countermeasures with business requirements.