Addressing Non-functional Requirements in Software Architecture

1. Addressing Non-functional Requirements in Software Architecture By: Dennis Bystritsky

2. What are Non-functional Requirements (NFRs)? • Specify criteria that can be used to judge the operation of a system, rather than specific behaviors • Example: Usability, dependability, security level, testability

3. How to address NFRs in system architecture? • Problematic • Can’t make a concrete module for something like “testability” • Should be a quality of the system as a whole • So can we even specify NFRs in early system architecture?

4. Lets first understand NFRs • NFRs are… • Operationalizable – implemented through functional components for the entire architecture (such as security) • Checkable – system can include components which check that the desired quality is met (such as performance)

5. Functional requirements and NFRs • Must be considered differently • Separation of concerns • Architecture components for FRs might realize some NFRs • We try to reduce “tangling”

6. First step? • Separate functional requirements from non-functional ones • Login screen • Progress bar • Administrator access • Help screen • Authentication • Security • Performance • Usability

7. Next… • Implement system architecture based on functional requirements • Should be relatively easy since each requirement links to one or more specific modules

8. Finally… • For each NFR… • Link it to one or more architectural modules • Feel free to create new modules as needed

9. How do we link? • XML binders • Use XML-style language to specify how NFRs link to functional components of the architecture

10. What we have done: • Separated FRs from NFRs • Created system architecture which addresses both sets of requirements • Reduced “tangling”

11. Future Work • Evaluation of software architecture • How to determine which architectures address requirements better than others