Architecture and requirements

  • Functional requirements—specify what the system must do and its behaviors under various
    circumstances.(e.g., requirement for GUI, databases, web services)
  • Quality attribute requirements—specify how to satisfy the functional requirements with the desired
    quality attributes. E.g., how fast the frame rate for screen display to support for video
  • Constraints—a constraint is a design decision that limits other possible decisions. Examples
    include the requirement to use a specified programming language.


  • Functionality is the capability of the system to do certain task.
  • Functionality does not completely determine an architecture.
  • Functionality can be divided up in any number of ways, and assigned to different architectural
    elements such as modules, layers, classes, services, databases, threads, etc.
  • Architectural elements are designed to support various quality attributes.
  • Functionality is independent of any architectural structures.
  • Functionality is achieved by assigning responsibilities to architectural elements.
  • Software architectures constrain the allocation of responsibilities, thereby preventing an arbitrary allocation.

Requirements for a good functionality

  • A functionality requirement should be unambiguous and testable. For example, “When the user
    presses ‘Enter’ on the keyboard, the details in the textfields will be captured and stored in the
  • It is desirable to have specific functionality. A specific functionality performs a specific
    task.A general functionality should be avoided in most of the situations.
    A specific functionality requirement would be more testable as compared to a general
    functionality requirement.
  • If a functionality requirement is too general, it is advisable to break it down to its component
    requirement.For example, “load data when the user presses on any button” is too general and ambiguous.

Quality Attribute

  • Quality attributes are related to the functionality of a system.
  • Quality attributes determine the functions of the system.
  • If a functional requirement is “when the user presses the button, the option dialog appears”:

    1. the performance of this function is about how quickly the dialog
    2. the availability of this function is about how often this dialog
      fails to appear (or: how frequent this dialog appears as intended)
    3. the user-friendliness of this function is about how easy it is to
      use this function.
    4. the modifiability of this function is about how easy it is to modify
      this feature in the coding space.

A quality attribute might not be able to be tested in a objective way

  • The definition of a quality attribute may not be testable in an objective way. For example, a system may be robust with respect to some faults but not others.
  • Sometimes a system’s issue could be relevant to more than one quality attribute. For example, a system failure due to a denial-of-service attack could be an issue of availability, performance, security, usability, and reliability.

Quality Attribute Scenario

  • Often, architects use quality attribute scenarios as a way of characterizing quality attributes—
    For example, to frame a system failure due to a denial-of-service attack within a scenario of
    availability, performance, security, usability, or reliability.
  • There are two general categories of quality attributes:

    • Attributes that describe some property of the system at runtime (such as availability,
      performance, speed)
    • Attributes that describe some property of the development of the system (such as modularity,
      modifiability, testability)
Last modification:June 27th, 2020 at 03:13 pm