Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Thursday, July 23, 2009

May the force be with you

Sometimes it is getting confusing. There are so many influential factors driving software architecture. Here is my small domain language
  • Forces is the set of all influential factors an architect is facing: requirements, risks, constraints, business needs.
  • Requirements are the (documented) set of all expectations for a software system. According to Wikipedia a requirement represents a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.
  • System requirements address the system as a whole. From system requirements we need to derive architecturally relevant requirements that drive architecture and design. That is the architect's job.
  • A Functional requirement defines functionality a system is supposed to provide, sometimes also known as capability. Use cases are functional requirements. They define what the user expects from the system on a black-box level. User stories according to Wikipedia denote software system requirements formulated as one or two sentences in the everyday or business language of the user.
  • A Non-functional requirement (also known as quality requirement, quality attribute or "ility") is constraining a solution. There are two subcategories here: operational requirements as the name suggests constrain the runtime behavior of the system (e.g., security, performance) while developmental requirements constrain the design from a developmental perspective (e.g., maintainability, modifiability). As operational requirements often have a systemic approach to a system they are subject to architecture design and therefore are also called strategic requirements. Tactical requirements such as modifiability mostly have only local scope.
  • Constraints - what a surprise - are constraining the solution. A constraint might be technical (we need to use Windows 7 as our OS), organizational (subsystem A should be developed at location A), standard & law (we must abilde to FDA rules), business-related (target costs should not exceed xxx$).
It is the job of a software architect to base all decisions on the forces of the project. Still she/he has sufficient freedom to make architecture and design a complex task. Architecture is about communication and courage to decide.

0 Comments:

Post a Comment

<< Home