Please enable JavaScript.

Coggle requires JavaScript to display documents.

Technical writing (Stylistic rules for natural language specification…

- - - - Advantages
        
        No limittions in expressiveness
        
        No communication barrier
        
        No special training required
      - Disadvantage
        
        Inherently ambiguous
        
        Prone to many types of defects
        
        Errors: jeopardise the project, failure
        
        Flaws: delay the project
- - - - Missing object, requirement or assumption
      - Unstate software response to some input
    - - Requirement documentation should ensure that the system-to-be will satisfy all objects including quality goals
      - Dedicated requirement to prevent undesirable effects
      - Describe the output for all possible inputs
      - Sufficient detail to allow for development
  - - - Train doors must always be kept closed between stations
      - Train doors must be opened once a train is stopped after an emergency signal
  - - - Requirements address the actual needs of the system-to be (explicitly or implicitly expressed by stakeholders)
      - Correctly describe laws in the problem space (environmental/physical assumptions must be realistic)
    - - If a book copy has not been returned one week after the third reminder has been issued, the negligent borrower shall be notified that he or she has to pay a fine of £ X
      - If a book has not been returned one week after the third reminder has been issued, a fine of £ X shall be retained from the borrower’s registration deposit and a notification will be sent to the borrower
  - - - Requirements formulated in a way that has only one interpretation
      - Terms are defined and used consistently
    - - Train doors shall be opened as soon as the train is stopped at a platform
      - The front of the train is (stopped) at a platform or The whole train is (stopped) at a platform?
  - - - Evaluation of alternatives
      - Verify satisfaction by an implmentation
      - Users to determine acceptance
- - - - A peer group review of software documents
      - Involves several people
      - Each person plays a defined role
      - Typically involves at least one person (usually an author) whose job is to introduce the documents to the rest of the group
      - In the context of requirements docs, walkthroughs are for training
    - - Manual process
      - Multiple readers
      - Checks for anamolies and omissions
      - Representatives of stakeholders should participate
      - In the context of requirements docs, reviews are for consensus
      - 2 ways
        
        Ad hoc
        
        Informal, non-systematic detection technique
        
        No explicit assignment of reviewer responsibility
        
        Relies on knowledge and experience of inspector
        
        Checklist
        
        Reuse of "lessons learned"
        
        Defines reviewer responsibilities
        
        Suggests ways for reviewers to identify defects
        
        Scenario
        
        Defect specific procedures
        
        Used to detect particular classes of defects
        
        Each reviewer executes a single scenario -> multiple reviewes needed to achieve broad coverage of the document
        
        Each review has a distinct responsibility