Lawrence Chung

Representing and using nonfunctional requirements: a process-oriented approach

A comprehensive framework for representing and using nonfunctional requirements during the development process is proposed. The framework consists of five basic components which provide the representation of nonfunctional requirements in terms of interrelated goals. Such goals can be refined through refinement methods and can be evaluated in order to determine the degree to which a set of nonfunctional requirements is supported by a particular design. Evidence for the power of the framework is provided through the study of accuracy and performance requirements for information systems. >

From object-oriented to goal-oriented requirements analysis

were proposed more than 10 years ago. The Object-Oriented Systems Analysis (OOSA) technique [12] adopts the Entity-Relationship (ER) model to capture the declarative aspects of a software system. This was soon followed by two new proposals, Object-Oriented Analysis [3] and the Object-Oriented Modeling Technique (OMT) [11], which support the modeling of declarative, behavioral as well as interactive aspects of a software system. Today, there are dozens of like-minded techniques and commercial tools founded on the OO way of thinking that support development from requirements analysis to implementation. Indeed, the great promise of OOA is that the whole software development process can be streamlined and simplified by having the same building blocks (objects, classes, methods, messages, inheritance and the like) used in all phases of development, from requirements to implementation. A recent proposal, the Unified Modeling Language (UML)—see www.rational. com/uml—attempts to integrate features of the more preeminent models in OOA, thereby enhancing reusability and consolidating the growing OOA market. Why is OOA popular? In a nutshell, because it significantly advances the state of practice in requirements modeling. The pracThe growing influence of object-oriented programming on programming practice

Dealing with non-functional requirements: three experimental studies of a process-oriented approach

Quality characteristics are vital for the success of software systems. To remedy the problems inherent in ad hoc development, a framework has been developed to deal with non-functional requirements (quality requirements or NFRs). Taking the premise that the quality of a product depends on the quality of the process that leads from high-Ievel NFRs to the product, the frameworks objectives are to represent NFR-specific requirements, consider design tradeoffs, relate design decisions to IYFRs, justify the decisions, and assist defect detection. The purpose of this paper is to give an initial evaluation of the extent to which the frameworks objectives are met. Three small portions of information systems were studied by the authors using the framework. The framework and empirical studies are evaluated herein, both from the viewpoint of domain experts who have reviewed the framework and studies, and ourselves as framework developers and users. The systems studied have a variety of characteristics, reflecting a variety of real application domains, and the studies deal with three important classes of NFRs for systems, namely, accuracy, security, and performance. The studies provide preliminary support for the usefulness of certain aspects of the framework, while raising some open issues.

Exploring alternatives during requirements analysis

Goal-oriented requirements analysis techniques provide ways to refine organizational and technical objectives, to more effectively explore alternatives during requirements definition. After selecting a set of alternatives to achieve these objectives, you can elaborate on them during subsequent phases to make them more precise and complete. The authors argue that goal-oriented analysis complements and strengthens traditional requirements analysis techniques by offering a means for capturing and evaluating alternative ways of meeting business goals. They detail the five main steps that comprise goal-oriented analysis. These steps include goal analysis, softgoal analysis, softgoal correlation analysis, goal correlation analysis, and evaluation of alternatives. To illustrate the main elements of the proposed analysis technique, they explore a typical scenario that involves defining requirements for a meeting scheduling system.

Dealing with Security Requirements During the Development of Information Systems

A growing concern for information systems (ISs) is their quality, such as security, accuracy, user-friendliness and performance. Although the quality of an IS is determined largely by the development process, relatively little attention has been paid to the methodology for achieving high quality. A recent proposal [32] takes a process-oriented approach to representing non-functional, or quality, requirements (NFRs) as potentially conflicting or harmonious goals and using them during the development of software systems. By treating security requirements as a class of NFRs, this paper applies this process-oriented approach to designing secure ISs. This involves identification and representation of various types of security requirements (as goals), generic design knowledge and goal interactions. This treatment allows reusing generic design knowledge, detecting goal interactions, capturing and reasoning about design rationale, and assessing the degree of goal achievement. Security requirements serve as a class of criteria for selecting among design decisions, and justify the overall design. This paper also describes a prototype design tool, and illustrates it using a credit card system example.

Using non-functional requirements to systematically support change

Non-functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Our NFR-framework treats NFRs as goals to be achieved during the process of system development. Throughout the process, goals are decomposed, design tradeoffs are analysed, design decisions are rationalised, and goal achievement is evaluated. This paper shows how a historical record of the treatment of NFRs during the development process can also serve to systematically support evolution of the software system. We treat changes in terms: of (i) adding or modifying NFRs, or changing their importance, and (ii) changes in design decisions or design rationale. This incremental approach is illustrated by a study of changes in banking policies at Barclays Bank.

Process-oriented metrics for software architecture evolvability

Evolution of software systems is almost a natural process. Evolution can occur at different levels of abstraction of software. Evolution at the architectural level, being the highest level of solution, can often times be the most critical to the success and survival of the pertaining software system. Metrics for software architectural evolvability will help determine the extent to which the architectural evolution can take place. We propose a framework called the POMSAE, process-oriented metrics for software architecture evolvability, that will help not only to intuitively develop architectural evolvability metrics but also to trace the metrics back to the evolvability requirements. This will then help analyze the reasons for the strengths/weaknesses in the metrics. POMSAE is partially validated by demonstrating its application to two practical telecom systems.

Architectural Design to Meet Stakeholder Requirements

Architectural design occupies a pivotal position in software engineering. It is during architectural design that crucial requirements such as performance, reliability, costs, etc., must be addressed. Yet the task of achieving these properties remains a difficult one and it is made even more difficult with the shift in software engineering paradigm from monolithic, stand-alone, built-from-scratch systems to componentized, evolvable, standards-based, and product line oriented systems. Many well-established design strategies need to be reconsidered as new requirements such as evolvability, reusability, time-to-market, etc., become more important. This paper outlines an approach that formulates architectural properties such as modifiability and performance as “softgoals” which are incrementally refined. Tradeoffs are made as conflicts and synergies are discovered. Architectural decisions are traced to stakeholders and their dependency relationships. Knowledge-based tool support for the process would provide guidance during design as well as records of design rationales to facilitate understanding and change management.

Implementation of a compiler for a semantic data model: Experiences with taxis

The features of a compiler for the Taxis design language are described and discussed. Taxis offers an entity-based framework for designing interactive information systems and supports generalisation, classification and aggregation as abstraction mechanisms. Its features include multiple inheritance of attributes, isA hierarchies of transactions, metaclasses, typed attributes, a procedural exception-handling mechanism and an iteration construct based on the abstraction mechanisms supported Developing a compiler for the language involved dealing with the problems of efficiently representing and accessing a large collection of entities, performing (static) type checking and representing isA hierarchies of transactions.

Dealing with change: An approach using non-functional requirements

Non-functional requirements (or quality requirements, NFRs) such as confidentiality, performance and timeliness are often crucial to a software system. Concerns for such NFRs are often the impetus for change. To systematically support system evolution, this paper adapts the ‘NFR Framework’, which treats NFRs as goals to be achieved during development. Throughout the process, consideration of design alternatives, analysis of trade-offs and rationalisation of design decisions are all carried out in relation to the stated goals, and captured in historical records. We show how such historical records of treating NFRs as goals also system-atically support system evolution. This approach is illustrated by a study of changes in loan policies at Barclays Bank. The study considered changes in NFRs, and associated changes in priorities, workload and functionality. The studys historical records helped quickly determine the impact of changes. We also present guidelines for consistently managing historical records, and address tool support for the change process.