Capturing Architectural Requirements.

Capturing Architectural Requirements.

1. A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.

2. Any requirement that is architecturally significant.

   • Implicit.
     • Have particular attributes.
       • high-risk
       • high-priority
       • low-stability
   • Explicit.
     • Often technical in nature, some are functional, some non-functional, some are independent of technical mechanisms, others are not.
       • The product supports multiple human languages.
         • Supportability requirement.
       • Persistence handled by a relational database.
         • Design requirement.
       • Specific database.
         • Implementation requirement.
       • 24/7 service.
         • Reliability requirement.
       • An online help system.
         • Functional requirement.
       • Presentation logic written in Visual Basic.
         • Implementation requirement.
       • The FURPS+ System for Classifying Requirements.
         • Functionality.
           • Represent the main product features, functional requirements
             • Auditing.
             • Licensing.
             • Localization.
             • Mail.
             • Online help.
             • Printing.
             • Reporting.
             • Security.
             • System management.
             • Workflow.
         • Usability.
           • Aesthetics and consistency in the user interface.
         • Reliability.
           • Availability, the amount of system "up time", accuracy of system calculations, and the system's ability to recover from failure.
         • Performance.
           • Throughput, response time, recovery time, start-up time, and shutdown time.
         • Supportability.
           • Testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.
         • +
           • Design requirements.
             • Specifies or constrains the options for designing a system.
           • Implementation requirements.
             • Specifies or constrains the coding or construction of a system.
           • Interface requirements.
             • Specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction.
           • Physical requirements.
             • Specifies a physical constraint imposed on the hardware used to house the system.

3. Architectural mechanisms.

   • Analysis Mechanism.
     • Represents an implementation-independent solution.
   • Design Mechanism.
     • Assumes some details of the implementation environment but is not tied to a specific implementation.
   • Implementation Mechanism.
     • Specifies the exact implementation of the mechanism.