Principles Of Software

Architecture
Lect#5
Software Architecture
• Is referred to both the process & design products required to
systematically build software systems that meet their intended
functions and quality
• The foundational software design activity that evaluates and
translates software requirements (both functional and
non-functional) into a collection of design elements that specify
structural and behavioral aspects of the major components of the
system, together with their provided quality, and interrelationships
required to support the detailed design and construction of
software systems; and the product resulting from such activity
Software Architecture Process
• Understand & Evaluate Requirements
• Design the Architecture
• Evaluate the architecture
• Document the architecture
• Monitor & Control Implementation
Understand & Evaluate Requirements
• Elicitation
• Requirement Sources(stakeholders, goal, domain knowledge, operational &
organizational environment)
• Elicitation Techniques
(interviews, facilitated meetings, observations, scenarios)
• Analysis
• Specification
• Validation
Perspectives
• Logical Perspective
• Configuration Management Perspective
Lect#6
 Analysis
• Impact of requirements on the system design
• Requirement classification (nature of requirements)
• Requirement prioritization (identification of most important function of the
software system)
• Requirement negotiation (remove conflicts)
• Conceptual modeling (identify the requirements context)
 Specification & Validation
• SRS
• Characteristics of requirements
• Specific
• Correct
• Complete
• Consistent
• Attainable
• Verifiable
Specific
 Correct
• Requirements need to be correct in the sense that they must
accurately describe a desired system function
Correct
 Complete
• Requirements should be complete both individually and as collective
set. This means that each requirement should be specified thoroughly
so that it absolutely describes the functions required to meet some
need
Complete
 Consistent
• Requirements are consistent when they do not prevent the
design or construction of other requirements When they do,
individual requirements or the SRS as a whole are referred to as
inconsistent
 Attainable
• Attainability is a property that spans many different characteristics
of the software system, including product characteristics such as
functionality as well as project characteristics such as cost and
schedule
• When specifying requirements, it is important to evaluate their
attainability under both cost and schedule constraints
Attainable
 Verifiable
• Perhaps the most obvious desirable characteristic of requirements in
practical applications is their verifiability.
• Requirements that cannot be verified cannot be claimed as met.
• Inability to verify requirements points to a serious flaw early on in the
development project , since requirements are the driving force of all
software development activities.
Verifiable
 Requirements Validation
• Requirements validation is the process of ensuring (through
well-known techniques) that the SRS provides a complete and
correct representation of what the stakeholders need