Stimulating architectural thinking during requirements elicitation - An approach and tool support
Preethu Rose Anish is a PhD student in the research group Services, Cybersecurity & Safety (SCS). Her supervisor is prof.dr. R.J. Wieringa from the Faculty of Electrical Engineering, Mathematics and Computer Science (EEMCS).
Requirements engineering (RE) activities involve capturing both functional and non-functional requirements of the software system to be developed. The software requirements specifications (SRS) resulting from these activities often lack the details needed by software architects (SAs) to make informed architecture design decisions. In turn, if wrong architectural decisions are made, the intended but unstated requirements will not be satisfied. To cope with the lack of information, the SAs either make assumptions or go back to the business analysts (BAs) for clarifications or conduct additional stakeholder interviews. However, assumptions, if incorrect, can lead to costly and time-consuming refactoring efforts at later project stages, while additional unplanned interviews by BAs can slow down time-to-market.
Asking BAs to provide architecturally richer specification seems like a plausible solution to this problem, but is going to be ineffective, given that BAs lack the technical architectural knowledge needed to ask the kind of questions that extract architectural details from the client. This is a typical scenario in global software engineering and outsourcing projects where communication between BAs and SAs mostly takes place through a SRS and expertise between these two professional groups is not shared.
Considerable academic research literature exists acknowledging that requirements are never detailed enough to make informed architectural decisions. However, to the best of our knowledge at the time of writing this dissertation, there is no systematic work done to remedy this situation.
Motivated by the problem scenario detailed above, this dissertation introduces an approach that leverages the knowledge of experienced SAs and makes it available to BAs to equip them to elicit architecturally richer specification.
Using an empirical research method, we first discovered an initial set of 15 architecturally significant functional requirements (ASFR) categories. We then identified a set of architecturally relevant questions pertinent to each ASFR category. We called them Probing Questions (PQs). We found that the PQs for the various ASFR categories can be organized in a logical sequence. We referred to these as PQ-flows. Having realized the practical scenario that the ASFRs and PQ-flows can grow based on specific project and business domain needs and technology advancements, we further created a knowledge base (KB) with the initial set of ASFRs and the corresponding PQ-flows to let the SAs evolve the KB with ASFRs and PQ-flows that are relevant to their project settings. We went a step ahead to provide automated support for recommending relevant PQ-flows for an SRS and then generating annotated PQ-flows wherein the annotations on the PQs contain possibly relevant requirements from the SRS that already answers some of the PQs. The BAs can leverage this information to determine what is already known, what knowledge is missing, and what effect this would have on the flow of the PQs.
