Whenever people ask me what my research is about, I constantly smile and answer fluently with the relationship / interplay / connection between software requirements and architecture, or sometimes mention ASRs and ADDs if they know more about the field. Then usually that’s the end of the conversation for that topic. However, if one day someone as an expert in this field asks me thoroughly from what I research on to what problems I am trying to solve from the industrial / academic perspective, and from what my goals of this research are to what methodology I am going to take etc, I don’t think I could be fluent again to give a clear answer. So to prepare for a rainy day, I’d better work out all the detailed answers for those questions in advance. Of course, to think about those questions has far more significant benefits than avoiding embarrassment of the previous situation. Anyway, here I’ll talk about my goals for my PhD combined with the problems that they are intended to solve.
It sounds very simple to say ‘I research on the relationship between software requirements and architecture’. However, what exactly does that indicate? Existing research has already claimed that requirements drive architecture and architecture can constrain and even inspire more requirements, which do demonstrate a kind of relationship between them. That is very general, conceptual, and high-level, while to fully understand the interplay between requirements and architecture, we still need more details so that could be applied in industry to solve their problems.
What problems do practitioners or projects have that are (partly) resulted from or could be solved or improved by this relationship? Capers Jones reports 30 software engineering issues that have stayed constant for 30 years in 2009. Among those issues, I identify at least three that are possible to benefit from my research if I could present a clearer and more detailed relationship between software requirements and architecture. And I’ll elaborate each of the three issues in the following three paragraphs.
Firstly, one issue is that initial requirements are seldom more than 50% complete. I presume the measuring method for this statistic is by comparing the initial requirements with the requirements embodied by the finished software product or the latest requirements documentation when the project finishes. There’s a significant time interval between this two measuring point. It is for cost and time to market reasons that design and implementation have to start before requirements are complete. And technically, initial requirements are unlikely and mostly not possible to be complete as changing is an inherent characteristic of requirements. However, can we make initial requirements much closer to complete such as 80% or 90% complete? Yes, this is one of my goals of my PhD. Requirements elicitation techniques are intended to address essential difficulties of requirements, while themselves usually entail accidental difficulties. Therefore, one of my goals targets the essential difficulties by better understanding of the interplay between requirements and architecture. Meanwhile, the accidental difficulties should be well controlled and mitigated. This goal focuses more on the quality of requirements rather than quantity, but the resulting requirements should be with more deepness and breadth, i.e. some requirements are thorough considered from the architecture’s perspective, thus less likely prone to change, and some requirements might be inspired by architecture, thus the inclusion of that type broadens the coverage of the initial requirements.