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

Metodología para elaboración de requerimientos en aplicaciones con servicios web

Depending on the technique used in the capture of requirements, it is possible to obtain innovative and iterative processes that truly support the construction of applications that consume web services. In the present article the elicitation approaches of the agile and traditional software methodologies are analyzed and the aspects of the rules that guarantee the concordance with the characteristics of the applications that consume services are taken, with the purpose of proposing a framework of work for the elicitation of the information applied to the specific case of applications that use web services. At the end of the article, a validation will be carried out in two companies that provide software development servicesDependiendo de la técnica usada en la captura de requerimientos, se pueden obtener procesos innovadores e iterativos que verdaderamente sirvan de soporte a la construcción de aplicaciones que consumen servicios. Las metodologías ágiles sugieren la elicitación de requerimientos altamente cambiantes, mientras que las metodologías tradicionales sugieren detallar al máximo los requerimientos luego de hacer un proceso de priorización. En el presente artículo se analizan los enfoques de elicitación de las metodologías ágiles y tradicionales y se toman los aspectos de cada una de ellas que guardan concordancia con las características de las aplicaciones que consumen servicios, lo anterior con el fin de proponer un marco de trabajo para la elicitación de requerimientos respecto al caso específico de aplicaciones que utilizan servicios web. Al finalizar el artículo se realiza una validación en dos empresas que prestan servicios de desarrollo de software

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