Donald Firesmith

Engineering Security Requirements

Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements, often confusing them with the architectural security mechanisms that are traditionally used to fulfill them. They thus end up specifying architecture and design constraints rather than true security requirements. This article defines the different types of security requirements and provides associated examples and guildlines with the intent of enabling requirements engineers to adequately specify security requirements without unnecessarily constraining the security and architecture teams from using the most appropriate security mechanisms for the job.

Security Use Cases.

Although use cases are a popular modeling approach for engineering functional requirements, they are often misused when it comes to engineering security requirements because requirements engineers unnecessarily specify security architectural mechanisms instead of security requirements. After discussing the relationships between misuse cases, security use cases, and security mechanisms, this column provides examples and guidelines for properly specifying essential (i.e., requirements-level) security use cases.

Specifying Reusable Security Requirements

Unlike typical functional requirements, security requirements can potentially be highly reusable, especially if specified as instances of reusable templates. In this column, I will discuss the concepts underlying security engineering including its quality subfactors. I will then address the issue of security requirements and how they differ from the architectural mechanisms that will fulfill them. Then, I will discuss the value of reusable parameterized templates for specifying security requirements and provide an example of such a template and its associated usage. Finally, I will outline an asset-based riskdriven analysis approach for determining the appropriate actual parameters to use when reusing such parameterized templates to specify security requirements.

Common Requirements Problems, Their Negative Consequences, and the Industry Best Practices to Help Solve Them

In this column, I summarize the 12 worst of the most common requirements engineering problems I have observed over many years working on and with real projects as a requirements engineer, consultant, trainer, and evaluator. I also list the negative consequences of these problems, and most importantly suggest some industry best practices that can help you avoid these problems, or at least fix them once they have raised their ugly heads. Although there is nothing really new here, these problems are well worth revisiting because they are still far too common, probably because the associated industry best practices are still far from being widely put into practice.

Specifying Good Requirements

Many of the characteristics of properly specified requirements have been well known for many years, at least among professional requirements engineers. Yet most requirements specifications seen today in industry still include many poor-quality requirements. Far too many requirements are ambiguous, incomplete, inconsistent, incorrect, infeasible, unusable, and/or not verifiable (e.g., not testable). To combat this sad state of affairs, this column provides a questionnaire that can be used when specifying and technically evaluating requirements.

Using Quality Models to Engineer Quality Requirements

There are a great number of different kinds of quality requirements. Consisting of a hierarchy of quality factors including associated quality characteristics and quality measures, a quality model provides a structured foundation on which to identify, analyze, and specify these quality requirements.

Engineering Safety and Security Related Requirements for Software Intensive Systems

Summary form only given. Many software-intensive systems have significant safety ramifications and need to have their associated safety-related requirements properly engineered. It has been observed by several consultants, researchers, and authors that inadequate requirements are a major cause of accidents involving software-intensive systems. Yet in practice, there is very little interaction between the requirements and safety disciplines and little collaboration between their respective communities. Most requirements engineers know little about safety engineering, and most safety engineers know little about requirements engineering. Also, safety engineering typically concentrates on architectures and designs rather than requirements because hazard analysis typically depends on the identification of hardware and software components, the failure of which can cause accidents. This leads to safety-related requirements that are often ambiguous, incomplete, and even missing. The tutorial begins with a single common realistic example of a safety critical system that will be used throughout to provide good examples of safety-related requirements. The tutorial then provides an introduction to requirements engineering for safety engineers and an introduction to safety engineering for requirements engineers. The tutorial then provides clear definitions and descriptions of the different kinds of safety-related requirements and finishes with a practical process for producing them

Towards Service-Oriented Enterprise Architectures for Big Data Applications in the Cloud

Applications with Service-oriented Enterprise Architectures in the Cloud are emerging and will shape future trends in technology and communication. The development of such applications integrates Enterprise Architecture and Management with Architectures for Services & Cloud Computing, Web Services, Semantics and Knowledge-based Systems, Big Data Management, among other Architecture Frameworks and Software Engineering Methods. In the present work in progress research, we explore Service-oriented Enterprise Architectures and application systems in the context of Big Data applications in cloud settings. Using a Big Data scenario, we investigate the integration of Services and Cloud Computing architectures with new capabilities of Enterprise Architectures and Management. The underlying architecture reference model can be used to support semantic analysis and program comprehension of service-oriented Big Data Applications. Enterprise Services Computing is the current trend for powerful large-scale information systems, which increasingly converge with Cloud Computing environments. In this paper we combine architectures for services with cloud computing. We propose a new integration model for service-oriented Enterprise Architectures on basis of ESARC - Enterprise Services Architecture Reference Cube, which is our previous developed service-oriented enterprise architecture classification framework, with MFESA - Method Framework for Engineering System Architectures - for the design of service-oriented enterprise architectures, and the systematic development, diagnostics and optimization of architecture artifacts of service-oriented cloud-based enterprise systems for Big Data applications.

Are Your Requirements Complete

Good requirements have several useful properties, such as being consistent, necessary, and unambiguous. Another essential characteristic that is almost always listed is that ‘requirements should be complete.’ But just what does completeness mean, and how should you ensure that your requirements are complete? In this column, we will begin to address these two questions by looking at (1) the importance of requirements completeness, (2) the completeness of requirements models, (3) the completeness of various types of individual requirements, , and (4) the completeness of requirements metadata. In next issue’s column, we will continue by addressing (5) the completeness of requirements repositories, (6) the completeness of requirements documents derived from such repositories of requirements, (7) the completeness of sets of requirements documents, (8) the completeness of requirements baselines, and finally (9) determining how complete is complete enough when using an incremental and iterative development cycle.

Engineering Safety Requirements, Safety Constraints, and Safety-Critical Requirements

As software-intensive systems become more pervasive, more and more safety-critical systems are being developed. In this column, I will use the concept of a quality model to define safety as a quality factor. Thus, safety (like security and survivability) is a kind of defensibility, which is a kind of dependability, which is a kind of quality. Next, I discuss the structure of quality requirements and show how safety requirements can be engineered based on safety’s numerous quality subfactors. Then, I define and discuss safety constraints (i.e., mandated safeguards) and safety-critical requirements (i.e., functional, data, and interface requirements that can cause accidents if not implemented correctly). Finally, I pose a set of questions regarding the engineering of these three kinds of safety-related requirements for future research and experience to answer.