QAW

QAW

1. Is

   • The QAW provides an opportunity to gather stakeholders together to provide input about their needs and expectations with respect to key quality attributes that are of particular concern to them.
     • this allows
       • A driving quality attributes of a software intensive system
         • this kind of software depends on
           • Software architecture for this reason the quality requeriments should be described concretely before and architecture is developed
             • The software architecture can be define by these definitios
               • The fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors
               • The structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them
             • We have to take in mind that
               • Although an architecture cannot guarantee that an implementation will meet its quality attribute goals, the wrong architecture will surely spell disaster
                 • For this reason
                   • The critical quality attributes must be well understood and articulated early in the development of a system, so the architect can design an architecture that will satisfy them.
                     • In wich way?
                       • 1. Identify scenarios from the point of view of a diverse group of stakeholders (e.g., architects, developers, users, sponsors). 2. These scenarios can then be used by the system engineers to analyze the system’s architecture and identify concerns (e.g., inadequate performance, successful denial-of-service attacks) and possible mitigation strategies (e.g., prototyping, modeling, simulation).
                         • all of these specification goint to
                           • Scenarios
                             • To be useful, a scenario must, at the very least, have a clear stimulus and response
                               • The stimulus is the part of the scenario that describes an agent or factor that initiates the system to react in some way.
                                 • Example
                                   • “An improved COTS discrete event generator product is available and required for the system.”
                               • The response is the system’s reaction to the stimulus.
                                 • Example
                                   • “An improved COTS discrete event generator product is available and required for the system.”
                                 • An important part of the response is a clear response measure
                                   • Example
                                     • “modify the system to incorporate the new discrete event generator”
                               • It also have an
                                 • Environment
                                   • That is the places where the scenario works, this helps to clarify the scenario
         • in this way
           • The earlier key quality attribute requirements are identified and prioritized
     • Focused
       • system-centric and stakeholder focused

2. The steps that involves it

   • QAW Presentation and Introductions
     • here
       • The QAW facilitators describe the motivation for the QAW and explain each step of the method.
   • Business/Mission Presentation
     • here
       • a representative of the stakeholder community presents the business and/or mission drivers for the system, the facilitators listen carefully and capture any relevant information that may shed light on the quality attribute drivers.
         • take it in mind
           • the system’s business/mission context
           • high-level functional requirements, constraints, and quality attribute requirements
   • Architectural Plan Presentation
     • here
       • At this point in the workshop, a technical stakeholder will present the system architectural plans as they stand with respect to these early documents.
         • this presentation have
           • plans and strategies for how key business/mission requirements will be satisfied
           • key technical requirements and constraints—such as mandated operating systems, hardware, middleware, and standards—that will drive architectural decisions
           • presentation of existing context diagrams, high-level system diagrams, and other written descriptions
   • Identification of Architectural Drivers
     • here
       • the facilitators will share their list of key architectural drivers and ask the stakeholders for clarifications, additions, deletions, and corrections. The idea is to reach a consensus on a distilled list of architectural drivers that include high-level requirements, business drivers, constraints, and quality attributes.
   • Scenario Brainstorming
     • here
       • After the architectural drivers have been identified, the facilitators initiate the brainstorming process in which stakeholders generate scenarios.
         • following these steps
           • Facilitators should help stakeholders create well-formed scenarios.
           • The vocabulary used to describe quality attributes varies widely.
           • Facilitators need to remember that there are three general types of scenarios and to ensure that each type is covered during the QAW
             • that are
               • use case scenarios - involving anticipated uses of the system
               • growth scenarios - involving anticipated changes to the system
               • exploratory scenarios - involving unanticipated stresses to the system that can include uses and/or changes
               • Facilitators should refer to the list of architectural drivers
   • Scenario Consolidation
     • here
       • facilitators ask stakeholders to identify those scenarios that are very similar in content. Scenarios that are similar are merged, as long as the people who proposed them agree and feels that their scenarios will not be diluted in the process.
   • Scenario Prioritization
     • here
       • The votes are counted, and the scenarios are prioritized accordingly.
   • Scenario Refinement
     • here
       • Further clarify the scenario 1. stimulus - the condition that affects the system 2. response - the activity that results from the stimulus 3. source of stimulus - the entity that generated the stimulus 4. environment - the condition under which the stimulus occurred 5. artifact stimulated - the artifact that was stimulated 6. response measure - the me
       • Describe the business/mission goals that are affected by the scenario
       • Describe the relevant quality attributes associated with the scenario.
       • Allow the stakeholders to pose questions and raise any issues regarding the scenario.