Talking about goals

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.

Secondly, requirements grow at about 2% per calendar month during development. Well, this issue has similar causes as the first one, which might be inadequate requirements process, low productivity and poor quality of requirements elicitation techniques etc. Then the first goal could equally help with this issue. What’s more, the challenge of the low productivity should be the focus for my second goal. One approach is to utilize requirements knowledge base. However, taken benefits of the first goal into consideration, a better solution should rely on a knowledge base which reflects the interrelationship between requirements and architecture.

The third issue is that there are more defects in requirements and design than in source code. Those defects could be inconsistency, ambiguity, or conflict etc in each or both of the requirements and design artifacts. This issue basically points out the poor quality problem, the difficulties of which lie largely on the interactions between requirements and design. Architecture is a very important artifact of design. Therefore, delving into the dependencies between requirements and architecture is indispensable to improve situations of this issue.

Ultimately, the relationship is a key to tackle down the above three issues. Although I have talked so many, there are still no goals clearly demonstrated. Well, probably that’s why it’s so hard to specify, especially to say it clearly and reasonably. So far, I think my ultimate contributions should be rooted in the relationship between software requirements and architecture, ASRs and ADDs in particular. To achieve that, it’s likely to be a model that embodies the relationship and hence could guide people, especially practitioners, to do better requirements engineering and even architectural design. Still sound too general and conceptual? Probably the above three issues are good examples to test whether I have reached the goals or not.