The Continuing Evolution Of Demand-oriented Software Architecture Decisions, Evaluation Methods

Along the process of software development and maintenance, requirements are always evolving. Requirements need to be fixed before design in traditional waterfall model, which cannot adapt to tight competition in software industry nowadays. Therefore, we need a formal requirement management a:roach to control requirement evolution in software development. At the same time, we need to change the design of software to adjust to change of requirements. However, developers seldom record alterations of software designs, ignoring changes of requirements during development process. Architects sometimes obtain software architectural decisions for explicit requirement with experiences and intuition, but they loss the whole process of making decisions. This results in arbitrary and un-repeatable decisions, separates requirement changes from decisions, and affects efficiency and cost of making decisions among requirement evolution.To solve the problems of obtaining the decisions along the requirement evolution, we first provide patterns of requirement evolution. We consider the process of requirement evolution as an affection of context and expectations of customers. As a result, functional requirements, quality requirements and context mutually affect and interconnect with each other. And also, customers usually focus on functional requirements quite differently from on quality requirements. For example, solutions sometimes only satisfy functional requirements without satisfying quality requirements; or satisfy essential quality requirements and ignore some functional requirements. During development and maintenance of software, these requirement evolution cases can be a guideline for software architecture design decisions. We present a development case to analyze requirement evolution in practice.After that, a methodological framework is proposed for prioritizing and choosing design decisions, which is based on assessment of quality attributes and design decision history. This framework is used to su:ort describing, documenting and choosing software architecture design decisions in requirement evolution. It divides requirements into a set of issues (sub-requirements), according to different contexts and different focuses of quality attributes. We organize stakeholders to evaluate importance of quality attributes, expectations, and importance of orthogonal issues, and then integrate alternative designs into legitimate total-solutions. Finally, we sort synthesized values and recommend a proper total-solution as a decision. In this article, we put this methodological framework into practice and discuss the result and future improvement.