Please enable JavaScript.

Coggle requires JavaScript to display documents.

Negotiation (Why (Requirement errors are the most expensive software…

- - - - The same concept is given different names in different statement
      - E.g. participate vs attending a meeting
      - Handling
        
        Use a glossary of terms that everyone agrees and sticks to
        
        Have a list of accepted synonyms
    - - The same concept is given different structures in different statement
      - E.g. excluded dates as a set of time points vs set of tim intervals
      - Handling
        
        Use a glossary of terms that everyone agrees and sticks to
        
        Have a list of accepted synonyms
    - - The same name designates different concepts in different statements
      - E.g. meeting participation as full vs partial participation
      - Handling
        
        Use a glossary of terms that everyone agrees and sticks to
        
        Have a list of accepted synonyms
    - - There are statements that cannot be satisfied when taken together; their logical conjunction evaluates to false in all circumstances
      - Clasical inconsistency in logic i.e. contradiction
      - E.g. constaints of participants may not be disclosed to anyone else vs meeting initiatior should know constraints
      - Handle by negotation
    - - There are statements that are not satisfiable together under some condition i.e. potential conflict
      - E.g. return a borrowed book within two weeks vs keep a borrowed book as long as he/she needs it
      - Handle by negotiation
  - - - Multiple stakeholders have different objectives and priorities
      - Such objectives are sometimes incompatible
    - - Non-functional requirements
      - Functional + non-functional requirements
    - - Password based authentication for increased security non-functional) often conflicts with usability requirements (non-functional)
      - Performance requirements (non-functional) about system throughput may conflict with safety requirements (non-functional)
- - - - Check "information" requirements vs confidentiality requirements that refer to related objects (e.g. users can be informed about book loan status vs students not alllowed to know which user has borrowed what)
      - Check requirements on decreasing some quantity vs requirements on increasing a related quantity (e.g. increase coverage of journal subscriptions vs decrease operational costs)
  - - - Not too soon
        
        To explore multiple alternative resolutions
        
        Allow for further elicitatioon of useful information within individual viewpoints in spite of their inconsistency with others
      - Not too late
        
        Before software development starts
        
        Could develop anything from inconsistent statements
    - - Drop lower-priority statements -> no conflict
      - Avoid weak conflicts: ensure in some way or another that the condition for conflict can never become true
      - Weaken conflicting statements: make the conflicting statements less restrictive so that the conflict no longer exists
      - Specialise conflict source or target: identify the source/target in conflicting statemments and specialise these so that the conflict disappears e.g. staff user can know about book loan status