EVALUATION OF CAPTURING ARCHITECTURALLY SIGNIFICANT REQUIREMENTS METHODS

Every software development organization strives for customer satisfaction. It is universally accepted that the success of software development lies in the clear understanding of the client requirements. During requirement elicitation and analysis stage, the system analyst identifies the functional and non-functional requirements from the customer. Security, usability, reliability, performance, scalability and supportability are the significant quality attributes of a software system. These quality attributes are also referred as non-functional requirements. Only a few functional and quality attributes requirement help to identify and shape the software architecture. A software system's architecture is the set of prime design decisions made about the system. If the requirement influences the architectural design decision then, it is referred as Architecturally Significant Requirement (ASR). Identifying and specifying all the possible ASR are important tasks in the requirement elicitation and analysis stage.In this research, general problems that are faced while capturing and specifying ASR in requirement elicitation and analysis is studied. Among the different requirement elicitation techniques, use case diagram has been identified and enhanced to solve the problem of capturing and specifying ASR during the requirement elicitation and analysis phase Â&nbsp

Planning strategically, designing architecturally : a framework for digital library services

In an era of unprecedented technological innovation and evolving user expectations and information seeking behaviour, we are arguably now an online society, with digital services increasingly common and increasingly preferred. As a trusted information provider, libraries are in an advantageous position to respond, but this requires integrated strategic and enterprise architecture planning, for information technology (IT) has evolved from a support role to a strategic role, providing the core management systems, communication networks, and delivery channels of the modern library. Further, IT components do not function in isolation from one another, but are interdependent elements of distributed and multidimensional systems encompassing people, processes, and technologies, which must consider social, economic, legal, organisational, and ergonomic requirements and relationships, as well as being logically sound from a technical perspective. Strategic planning provides direction, while enterprise architecture strategically aligns and holistically integrates business and information system architectures. While challenging, such integrated planning should be regarded as an opportunity for the library to evolve as an enterprise in the digital age, or at minimum, to simply keep pace with societal change and alternative service providers. Without strategy, a library risks being directed by outside forces with independent motivations and inadequate understanding of its broader societal role. Without enterprise architecture, it risks technological disparity, redundancy, and obsolescence. Adopting an interdisciplinary approach, this conceptual paper provides an integrated framework for strategic and architectural planning of digital library services. The concept of the library as an enterprise is also introduced

Missing Requirements Information and its Impact on Software Architectures: A Case Study

[Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

Probing for requirements knowledge to stimulate architectural thinking

Software requirements specifications (SRSs) often lack the detail needed to make informed architectural decisions. Architects therefore either make assumptions, which can lead to incorrect decisions, or conduct additional stakeholder interviews, resulting in potential project delays. We previously observed that software architects ask Probing Questions (PQs) to gather information crucial to architectural decision-making. Our goal is to equip Business Analysts with appropriate PQs so that they can ask these questions themselves. We report a new study with over 40 experienced architects to identify reusable PQs for five areas of functionality and organize them into structured flows. These PQflows can be used by Business Analysts to elicit and specify architecturally relevant information. Additionally, we leverage machine learning techniques to determine when a PQ-flow is appropriate for use in a project, and to annotate individual PQs with relevant information extracted from the existing SRS. We trained and evaluated our approach on over 8,000 individual requirements from 114 requirements specifications and also conducted a pilot study to validate its usefulness.</p

From internet architecture research to standards

Many Internet architectural research initiatives have been undertaken over last twenty years. None of them actually reached their intended goal: the evolution of the Internet architecture is still driven by its protocols not by genuine architectural evolutions. As this approach becomes the main limiting factor of Internet growth and application deployment, this paper proposes an alternative research path starting from the root causes (the progressive depletion of the design principles of the Internet) and motivates the need for a common architectural foundation. For this purpose, it proposes a practical methodology to incubate architectural research results as part of the standardization process

A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201

Functional Consistency across Retail Central Bank Digital Currency and Commercial Bank Money

Central banks are actively exploring central bank digital currencies (CBDCs) by conducting research, proofs of concept and pilots. However, adoption of a retail CBDC can risk fragmenting both payments markets and retail deposits if the retail CBDC and commercial bank money do not have common operational characteristics. In this paper, we focus on a potential UK retail CBDC, the 'digital pound', and the Bank of England's 'platform model'. We first explore how the concept of functional consistency could mitigate the risk of fragmentation. We next identify the common operational characteristics that are required to achieve functional consistency across all forms of regulated retail digital money. We identify four design options based on the provision of these common operational characteristics by the central bank, payment interface providers (PIPs), technical service providers (TSPs) or a financial market infrastructure (FMI). We next identify architecturally-significant use cases and select key capabilities that support these use cases and the common operational characteristics. We evaluate the suitability of the design options to provide these key capabilities and draw insights. We conclude that no single design option could provide functional consistency across digital pounds and commercial bank money and, instead, a complete solution would need to combine the suitable design option(s) for each key capability and include common ecosystem services provided by an FMI and TSPs.Comment: 24 pages, 3 figures, 3 table

Walley School Community Arts Center Feasibility Study: Appendices

Having a large capacity (over 300 seats) in Walley School demands a major investment in space and cost. Taking this into consideration, the business planning team conducted research and spoke with several individuals in an attempt to inventory and assess the community’s auditorium capabilities. Our research on existing auditorium spaces uncovered many interesting things. We found that there are over 15 existing auditorium spaces available within a 17-mile radius from the Walley School building available for public use