Please enable JavaScript.

Coggle requires JavaScript to display documents.

Elicitation techniques and types of requirements (Questionnaires…

- - - - Organise meeting (real/virtual)
      - Prepare agenda + questions
      - Select specific stakeholder
    - - Assign a person to take the minutes
      - Facilitator controls the meeting
    - - Write a summary from interview transcripts
      - Submit the summary/minutes to the interviewee for validation + refinement
  - - - Pre-established set of questions
      - Questions can be open-ended / ask for a choice among several answers provided
      - More focused discussions
      - Might not know what questions to ask if don't understand the solution/industry -> cannot give extra information
    - - No pre-established set of questions
      - Free, informal discussion
      - Exploration of issues
      - Client controls the discussion -> might miss things you want to know
- - - - Functional effects that the software-to-be is required
      - Address the 'What' aspect
      - Linked to functional goals
      - Address single points of functionality
    - - Quality (linked to quality goals): contraints on the way the software-to-be should satisfy its functional requirements; addresses 'How well'
        
        Safety: rule out software effects that might result in accidents, degradations or losses (e.g. The controlled accelerations of trains shall always guarantee that a worst-case stopping distance is maintained between successive trains.)
        
        Security: prescribe the protection of system assets against undesirable behaviours
        
        Confidentiality: some sensitive information may never be disclosed to unauthorised parties (e.g. A non-staff patron may never know which books have been borrowed by others.)
        
        Integrity: some information may be modified only if correctly done and with authorisation (e.g. The return of book copies shall be encoded correctly and by library staff only.)
        
        Availability: some information/resource can be used at any point in time when it is needed and its usage is authorised (e.g. Information about train positions shall be available at any time to the vital station computer.)
        
        Reliability: contrains the software to operate as expected over long periods of time (e.g. The train acceleration control software shall have a mean time between failures of the order of 100 hours.)
        
        Performance: constrain the software's operational conditions, usch as time/space required by operations, the frequency of their activation, their throughput, the size of their input/output (e.g. Acceleration commands shall be issued to every train every 3 seconds)
        
        Interface: input/output formmats and interaction sequences should be compatible with what the environment expects
        
        Human interaction: usability requirements prescribe input/output formats and user dialogues to fit the abstractions, abilities and expectations of target users (e.g. To ensure smooth and comfortable train moves, the difference between the accelerations in two successive commands sent to a train should be at most X.)
        
        Device interaction
        
        Software interoperatibility (e.g. The meeting scheduling software should be interoperable with the WSS Agenda Manager product.)
        
        Accuracy: constrain the state of information processed by the software to reflect the state of the corresponding physical information accurately (e.g. A copy of a book shall be stated as available by the loan software if and only if it is actually available on the library shelves.)
      - Compliance: prescribe software to conform to national laws, international regulations, social norms, cultural or political constraints, and standards (e.g. The value for the worst-case stopping distance between successive trains shall be compliant with international railways regulations)
      - Architectural
        
        Installation: e.g. The meeting scheduling software should run on Windows version X.x and Linux version Y.y.
        
        Distribution: e.g. The on-board train controllers shall handle the reception and proper execution of acceleration commands sent by the station computer.
      - Development: requirements on development costs, delivery schedules, variability of features, maintainability, reusability + portability (e.g. The overall cost of the new UWON library software should not exceed X.)
      - Classified with a taxonomy
        
        Requirement categories allows us to characterise more explicitly what requirements refer to as prescribed by the taxonomy
        
        Use as a chcecklist to idenitfy any missing requirements
        
        Non-functional requirements address cross-cutting concerns