I recently gave a presentation to the International Conference on Global Software Engineering on a notation for coordination models.
You can find it at http://www.sei.cmu.edu/library/abstracts/presentations/icgse-bass-2010.cfm
- Len Bass, SEI
I recently gave a presentation to the International Conference on Global Software Engineering on a notation for coordination models.
You can find it at http://www.sei.cmu.edu/library/abstracts/presentations/icgse-bass-2010.cfm
- Len Bass, SEI
The primary purpose of the architecture for a software-reliant system is to satisfy the driving behavioral and quality attribute requirements. Quality attribute requirements tend to be poorly captured and poorly represented in requirements specifications, which focus on functionality. It is often up to the architect’s own initiative to capture the actual quality attribute requirements for a system under development.
In the last post, I introduced the testing situation—when is testing complete, how are tests performed, and what are the results of the tests? In this post, I discuss the test cases themselves: important use cases, architecturally significant requirements, and view-specific use cases.
Some use cases are more important than others. These are the use cases that characterize the functionality of the system in broad terms. If these use cases are satisfied, the other functionality should be added easily. These are not the architecturally significant requirements, which I will discuss next; these are use cases that expose functionality.