Yesterday`s post I talked about the answer to part C of the CAD architecture question. The answer seems to want you to talk about the two ways to do architectural analysis of questioning and measuring. Though I see this as the answer especially because of a comment I got from my adviser while going over a previous test I cannot pass over this question without a complaint. It seems that he implied an answer from the book "Software Architecture in Practice by Bass, Clements and Kazaman". The answer comes in the introduction to part III of the book. The questioning part of the answer seems to be incomplete. In this book the answer comes from the point of view of the Architectural Business Cycle or ABC. In other words you would be providing a questionnaire to your stakeholders and others involved in the project. I say the question on the test is incomplete because it affirms that the requirement is already concrete. The questioning technique described in this book happens early enough in the process that it could be that meeting this requirement mean not meeting it at all. An architect would talk to the stakeholder and discover that through push back with cost it is not really 3 seconds but longer is tolerable. Example: You would need a local workstation with replicated storage to be able to open any drawing within 3 seconds. We have decided to use centralized storage and allow for network latencies that would lead to longer than a 3 second retrieval time. Because of my learning disability I read this question literally. The answer type given above is not in my arsenal to answer the question. It is ruled out because the question is written affirming the concrete 3 second retrieval time. Also, experience plays a part in the previous answer type. This kind of experience, even hypothetically, I don`t have. This kind of architectural call limits my thinking for answering the test question. In the real world I would have to shift over to prototypes and measuring to really answer the architectural questions. As you know from previous posts I was not give credit for that kind of answer an previous tests even though I had a very complete mathematical derivation. Another type of questioning is internalized questioning. This was not implied as the correct answer by my adviser at our meeting. The reason I think this is that the implied answer comes from a different book mentioned above. This internalized type of questioning comes from "Applying UML and Patters by Craig Larman". This kind of internalized questioning is described in relationship to the UP process and how the Software Architecture Document would be done. The author talks about FURPS+. It is a mnemonic developed by Robert Grady while at HP. This mnemonic stands for Functionality, Usability, Reliability, Performance, and Supportability. The plus part is for Design Requirements, Implementation Requirements, Interface Requirements, and Physical Requirements. The questioning is done as an exercise in learning about the system. This kind of questioning helps to systematically go through parts of the system and make educated guesses about meeting requirements. Then after the guesses recording them in the SAD as risk and possible solution. The cost factors are also used in evaluation as above in the other type of questioning but the requirement is more concrete. Through iteration in the UP it may be revisited but the analysis is done and through educated guess you may be able to say if you can or cannot meet the requirement before implementation. I see differences in the approaches to questioning. Still neither is as concrete as measuring. They both take place it seems not in relationship to a concrete requirement as how the question was phrased on the test. So I am back to being stumped on how to answer the question. It seems as both are wrong in some way. In the real world you would either have an educated guess that would be supported by your man paying the bills or they would ask you to have more concrete metrics by measuring prototypes. The test writer needs to re-write this question.