Software Architecture Design - PowerPoint - PowerPoint

Document Sample
Software Architecture Design - PowerPoint - PowerPoint Powered By Docstoc
					2. Life-Cycle Perspective
Overview

   2.1 Motivation
   2.2 Waterfall Model
   2.3 Requirements in Context




                                  [ §3 : 1 ]
2.1 Motivation
   Premise of modern software engineering
       design/planning must consider product’s entire life
       this is a central and essential assumption
   In contrast, a more narrow perspective
       e.g., development only
       is likely to lead to failures
       lacks dependability assurances
       risks later expenses much > development costs


                                                   [ §3 : 2 ]
2.1 Motivation, Continued

   Other life-cycle concerns also fundamental
       maintainability, extensibility, portability, etc.
       must be considered throughout life-cycle as well
   Life-cycle starts with requirements definition
       … upon which everything that follows depends




                                                   [ §3 : 3 ]
2.2 Waterfall Model as Overview
                                      Requirements
   Understanding                       definition


    requirements                                System
       presupposes a good                      design


        grasp of the development
                                                     Softw are
        process as a whole                            design


   Waterfall model                                      Implementation
                                                          and unit testing
       remains one of the best
        abstractions for the entire                                  Integration
        development process                                           and testing



                                                                             Operation and
                                                                             maintenance




                                                                                    [ §3 : 4 ]
Multiple Development Perspectives
   Waterfall model
       product focused
   Spiral (Boehm)
       driven by risk analysis and mitigation
       planning, risk assessment, engineering, customer evaluation
   Evolutionary
       e.g. XP (Beck)
       increment driven
       rapid prototyping, regression testing, evolution
   Transformational
       specification driven
       formal methods


                                                           [ §3 : 5 ]
          2.3 Requirements in Context
   Requirements may vary
        in level of abstraction, contents
        from one context to another
   System requirements                                   constraints


        result from an analysis or discovery
                                                problem
                                                          Requirements                 system
         process                                            definition                 requirements
                                                needs

   Software requirements                                           System
                                                                                       software
                                                                                       requirements
                                                                    design
        result from a design process
         involving requirements allocation                               Softw are
                                                                          design
   Sometimes there is no distinction
    between them



                                                                                     [ §3 : 6 ]
3. Software Requirements Defined


   3.1 Issues
   3.2 Functional Requirements
   3.3 Non-functional Requirements
   3.4 Significance



                                      [ §3 : 7 ]
3.1 Issues
   What are requirements?
   Why are they significant?
   When are they generated?
   How are they generated?
   How are they documented?
   How are they managed?
   When are they discarded?
   Can requirements be implicit?


                                    [ §3 : 8 ]
    Simplifying Assumptions
                                    application
   For now, ignore how
    requirements are
                                    Requirements
    generated                         definition           software
                                                           requirements
       e.g., from customer needs            Program
                                              design
   Consider a very simple
    life cycle model                                 Coding
                                                   and testing




                                                                   [ §3 : 9 ]
Terminology
   A requirement is a technical objective which is imposed upon
    the software, i.e., anything that might affect the kind of software
    that is produced
   A requirement may be imposed by
        the customer
        the developer
        the operating environment
   The source, rationale, and nature of the requirement must be
    documented
   Requirements fall into two broad categories
        functional
        non-functional



                                                             [ §3 : 10 ]
3.2 Functional Requirements
   Functional requirements are concerned with what the software
    must do
        capabilities, services, or operations
   Functional requirements are not concerned with how the
    software does things, i.e., they must be free of design
    considerations
   Functional requirements are incomplete unless they capture all
    relevant aspects of the software’s environment
        they define the interactions between the software and the
         environment
        the environment may consist of users, other systems, support
         hardware, operating system, etc.
        the system/environment boundary must be defined



                                                                [ §3 : 11 ]
Important Messages
   Requirements are difficult to identify
   Requirements are difficult to write
   Requirements change over time
   Discrepancies between needs and
    capabilities may render the software useless
   Life-cycle considerations must be
    documented since they have design
    implications

                                          [ §3 : 12 ]
Communication Issues
   Missing or vague requirements are a recipe for disaster
   Anything that is not made explicit may not be implemented or
    considered
   Anything that is ambiguous is likely to get implemented in the
    least desirable way
   Standard trade practices may be omitted (in principle!)
   Cultural settings do affect the way in which requirements are
    written and read
   Multiple views may be required to formulate a reasonably
    complete set of requirements




                                                           [ §3 : 13 ]
Implicit Requirements
   An interface specification can become a
    requirement definition only if
       it is the only processing obligation
       its semantics are well defined
   A product cannot be its own requirements
    definition because
       the rationale for the design decisions is lost
       there is no verification criterion


                                                    [ §3 : 14 ]
Non-Functional Requirements
   Non-functional requirements place restrictions on the
    range of acceptable solutions
   Non-functional requirements cover a broad range of
    issues
       interface constraints
       performance constraints
       operating constraints
       life-cycle constraints
       economic constraints
       political constraints
       manufacturing


                                                 [ §3 : 15 ]
Important Messages
   Constraints are the main source of design
    difficulties
   No formal foundation on which to base the
    treatment of most non-functional
    requirements is available today
   Non-functional requirements are at least as
    dynamic as the functional ones



                                          [ §3 : 16 ]
Case Study: Sensor Display
   Consider a small system that displays the status of
    several sensors (e.g., pressure, temperature, rate of
    change, etc.) on a limited-size screen
   What are some of its functional requirements?
   What are some of its non-functional requirements?



               display
                         System




                                                  [ §3 : 17 ]
3.4 Significance
   Requirements are the foundation for the software development
    process
   Requirements impact the life cycle throughout its phases
       customer/developer interactions
       contractual agreements
       feasibility studies
       quality assurance
       project planning
       risk analysis
       testing
       user documentation




                                                        [ §3 : 18 ]

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:18
posted:9/11/2012
language:Unknown
pages:18