[INF43] Lecture 3 How do we know waht to build

软件工程 SoftwareEngineering


@ZYX 写于2020年04月08日

How do we know what to build part 1

1. Software Failures

  1. What is the real problem
    1. Complexity
      1. banking system is hard, bank rule is complex
    2. Conformity
    3. Progress is hard to measure
    4. "legacy" system
      1. there are some bugs in the old systems which are hard to maintain
    5. "Hubble Psychology"
      1. project tend to be unrealistic -> more money more people

2. Why requirements

  1. if you are requirement engineer, you should make sure that your list is complete and nothing important is ignored
  2. Complete? Unambigous? Non-conflicting? Verifiable?
    1. verifiable == there is an eaysy and straightforward way to verify the requirement is met
      ex: The average user can easily use the app -> The average user shall be able to create a list with 3-5 items
    2. Unambigous -> a new list item is added at the top of the list/ name should be 50 character maximum
    3. Non-conflicting -> consistent, 说的要是同一件事情
  3. Reminder: TOP software failure Causes(与需求相关的):
    1. Lack of user input/involvement
    2. Incomplete requirements and specifications
    3. Changing requirements and specifications

3. Requirements

  1. Definition:
    Requirements = what the software should do without saying how it should do it
    (requirements address what a customer needs, not a customer wants)

    1. 67% of time was used on maintainance
      1. which can be reduced by better requirement documentation
    2. "In-house staff writing systems for internal use" employs the most computer programmers in the U.S.
    3. Requirement documentation正式程度:
      1. Consulting companies/contract programming
      2. Games, apps, productivity software
      3. In-house staff writing systems for internal use
    4. Waterfall:
      1. Requirement analysis
      2. Requirement sepecification
      3. Design
      4. Implementation
      5. Verification
      6. Maintenance
  2. Requirements Phase Terminology

    1. Requirement analysis -> acitivity of discovering/observing/gathering customer’s needs
    2. Requirement specification -> activity of describing/documenting customer’s needs
      1. also called requirement documentation
  3. Techniques for requirement analysis

    1. Interview customer
    2. Observe customer (CNBC article)
    3. Create use cases/scenarios/user stories
    4. Prototype solutions
    5. Identify important objects/roles/functions/goals
      e.g., CRUD
    6. Perform research
    7. Construct models
    8. Data-driven requirements analysis
      • Usage data is analyzed and business metrics are recorded to discover the value of new (potential) features
      • Techniques
        1. Data analytics
        2. A/B testing
        3. Prototyping
        4. Market research
      • This information is used to create/prioritize/analyze/evaluate requirements
  4. Requirements specification:

    1. Serves as the fundamental reference point between customer and software producer
    2. Defines
      1. the “what,” not the “how”
      2. environmental requirements on the software
      3. constraints on the software
      4. software qualities
    3. Why Spend a Lot of Time?
      • A requirements specification is the source for all future steps in the software life cycle
      • Changes are cheaper now than later
  5. Users of Documents

    • Customers
    • Developers
    • Managers
    • Testers
    • Documenters
    • Maintainers
    • System engineers
    • Software architects
    • Marketing personnel
  6. Document Structure

    1. Introduciton
      1. What is this docment about
      2. Who was it created for?
      3. Who created it?
      4. Outline
    2. Executive summary
      1. Short, succinct, concise, to-the-point, description
      2. Identifies: main goals, key features, key risks/obstacles
      3. Many people do not read all the document and only read this summary
    3. Application context
      • Describes the situation in which the software will be used
        • Home, office, inside, outside, …
      • Identifies all things that the system affects
        • Objects, processes, other software, hardware, and people
    4. Environmental requirements
      • Platforms
        • Hardware
          • Operating systems, types of machines, memory size, hard disk space
        • Software
          • Is it a Web app? Mobile app? Desktop app?
          • Is it open source? Linux? Apache? PHP/MySQL?
          • Is it enterprise software? .Net? Enterprise Java, J2EE?
      • Programming language(s)
      • Standards
    5. Functional requirements
      • Identifies all concepts, functions, features, and information that the system provides to its users
      • Provides an abstraction for each of those, characterizing the properties and functions that are relevant to the user
        What is the system supposed to do?
        What information does the system need?
        What is supposed to happen when something goes wrong?
    6. Software qualities (Desired Software "ilities")
      • Correctness
      • Reliability
      • Efficiency
      • Usability
      • Maintainability
      • Portability
      • Reusability
      • Interoperability
      • Robustness
      • Security
      • Scalability
    7. Other requirements
      What about cost?
      What about documentation?
      What about manuals?
      What about tutorials?
      What about on-the-job training?
      What about requirements that do not fit in any of the previous categories?
    8. Time schedule
      • By when should all of this be done?
        Initial delivery date
        Acceptance period
        Final delivery date
      • What are some important milestones to be reached?
        Prototype delivered
        Architecture/design/implementation/testing completed
        Sprint/increment 1/2/3 etc. completed
    9. Potential risks
      • “future uncertain events with a probability of occurrence and a potential for loss”
    10. Assumptions
      • Factors that are believed to be true during the life cycle of the project. If changed, they may affect the project outcomes negatively
        end-user characteristics
        known technology infrastructure
        resource availability
        funding availability
    11. Future changes
      • Any project faces changes over time
        It is important to identify those changes up-front so you and the customer are aware of them
      • Structure the requirements document in such a way that it easily absorbs changes
        • Define concepts once
        • Partition separate concerns
        • Avoid redundancy
    12. Glossary
      • Precise definitions of terms used throughout the requirements document
    13. Reference documents
  7. Specification Methods

    • Natural language
      SRS, user stories
    • Diagrams
      Data flow, finite state machines, Petri nets
    • Formal language
      Z, TLA+
    • Models
      Domain model (objects), usage model (use cases), goal model
  8. Verification
    Is the requirements specification complete?
    Is each of the requirements understandable?
    Is each of the requirements unambiguous?
    Are any of the requirements in conflict?
    Can each of the requirements be verified?
    Are are all terms and concepts defined?
    Is the requirements specification unbiased?

  9. Acceptance Test Plan
    Often accompanies a requirements specification
    Specifies how it will be determined that each requirement is met
    Binds a customer to accept the delivered system if it passes all the tests

  10. Ziv’s Law

    • Software development is unpredictable and the documented artifacts such as requirements will never be fully understood
    • Uncertainty is inherent and inevitable in SE processes and products!