Please enable JavaScript.

Coggle requires JavaScript to display documents.

**CHAPTER 4 (PART 2 (Problems of requirements analysis (Stakeholder…

- - - - application domain
      - services system should provide
      - system's operational constraint
    - - Requirement discovery
        
        Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.
      - Requirement classification and organization
        
        Groups related requirements and organises them into coherent clusters.
      - Requirement prioritisation and negotiation
        
        Prioritising requirements and resolving requirements conflicts.
      - Requirements specification
        
        Requirements are documented and input into the next round of the spiral.
  - - - Closed interviews : based on pre-determined list of questions
      - Open interviews : where various issues are explored with stakeholders.
    - - Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders.
      - Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.
  - - - A description of the starting situation
      - A description of the normal flow of events
      - A description of what can go wrong
      - Information about other concurrent activities
      - A description of the state when the scenario finishes
  - - - Requirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to work.
      - Requirements that are derived from cooperation and awareness of other people’s activities.
      - Ethnography is effective for understanding existing processes but cannot identify new features that should be added to a system.
  - - - Requirements reviews : Systematic manual analysis of the requirements.
      - Prototyping : Using an executable model of the system to check requirements.
      - Test-case generation : Developing tests for requirements to check testability.
  - - - Verifiability : Is the requirement realistically testable?
      - Comprehensibility : Is the requirement properly understood?
      - Traceability : Is the origin of the requirement clearly stated?
      - Adaptability : Can the requirement be changed without a large impact on other requirements?
  - - - The business and technical environment of the system always changes after installation.
      - The people who pay for a system and the users of that system are rarely the same people.
      - Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory.
    - - Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced with other requirements.
      - A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section.
      - Traceability policies These policies define the relationships between each requirement and between the requirements and the system design that should be recorded.
      - Tool support Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.
    - - identified problem
        
        Problem analysis and change specification
        
        Change analysis and costing
        
        Change implementation
        
        Revised requirement
- - - - The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.
  - - - May serve a dual function
        
        Basis for a bid for a contract
        
        Must be open to interpretation
        
        Basis for the contract itself
        
        Must be defined in detail
        
        Both these statements may be called requirements
  - - - Example: Client managers, System end-users
    - - Example: Software Developers, System architects
  - - - definition of user requirement
      - specification of user requirements
  - - - Precision is difficult without making the document difficult to read
    - - Functional and non-functional requirements tend to mixed-up
    - - Several different requirements may be expressed together