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. 

Why I started my PhD

A lot of people choose to work on a particular profession either because they can do it or believe they could do it very well from their past experience, or because they really love that kind of work and are eager to devote their energy and time into it. Then in my case, I am more of the first type of person (while for what I love to do is currently not that strong enough to make it a career). I am qualified with very good scores in college and I can learn and understand the whole software and programming stuff very quickly. On the other hand, I do have some enjoyable time when designing software and coding. Well, it’s hard to distinguish whether it’s the discipline itself or the achievement out of studying that gives me the joy.

There was a time in my second year that I was obsessed in reading the Programmer magazine. It is a Chinese magazine and talks a lot of new technologies, current situations and famous persons in China IT industry. It was at that time I was exposed to the words such as SOA, and most important of all, software architects. Well, you can imagine how hard it is to read those articles for a second year student who has just stepped into the world of programming and software for only one year. Despite of those obscure concepts in those articles, ‘architects’ catches my eyes all the time. I got to know that there are only a few real architects in China and it is very hard to become an architect.  I had a strong fascination on architects because of their great power and magical ability to map out the software without really coding as I understood at that time. Hence I then was determined to become an architect in the future.

But two years later, I am much clearer about how difficult it is to become an architect. And I know that the situations for programmers in Chinaare really not as what I expected, combined with the fierce competitions among peers and the fact that I still think my knowledge in this field is too little to guarantee a relatively smooth shortcut to become an architect. As a result, I chose to pursue further education which is essentially why I end up here as a PhD student. This is not a very strong motivation from an academic perspective and consequently to a large extent it brings me some challenges during my research.

While most of my courses in Jilin Universityfocus on the computer science part which are hard technologies and theories as opposed to the soft part of software engineering such as software analysis and design, development process, quality assurance etc. I can do programming very well but I don’t think I’d like to work with computers most of the time for jobs in the future. I prefer communications with people. And I believe I have good personal communication skills (at least among friends…). Therefore, requirements attracted my attention in my third year. Well, I have to mention that Norah and probably J.J. as well regard me as a shy girl, which to be honest really strikes me out. None of my friends or people who know me in China would think me any closer to ‘shy’. But as a matter of fact, when I look at how I behave here in UL, it seems yes, I really look shy… Why is this happening? Because of cultural difference? I don’t know yet. But no matter what circumstances I am, I really should just be the real me.

At the beginning, I was with great confidence that doing a PhD, though much tougher than and different from finishing undergraduate, should be just another challenge in study, definitely a thing within my capability to manage well. But looking back now when I am in my second year through PhD, I find that confidence is really naïve and out of no where. Though I still hold confidence that I am a capable person to finish my study, what I miss at the starting point is that I haven’t thoroughly thought about and understood what kind of challenges in and the real essence of PhD research. I started this PhD journey without a clear goal unlike the cases of most PhD students starting after years of industry experience who are often equipped with strong motivation, clear questions and goals in their mind. What I say here doesn’t mean that I never think about what my goals are. The fact is that my goals change very often and are not clear at all as I am not that determined about what I really want. So I wonder things around and hence there are even times that I lost goals. But now I think it’s time to make it clear and when it changes later, just make it clear again. As the benefit of a clear goal in mind is same as that of a beacon for a ship, I do need it to guide me now.