Please enable JavaScript.

Coggle requires JavaScript to display documents.

SWE102 - 4 - Requirements Engineering (The software requirements document,…

- - - - Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
      - Often apply to the system as a whole rather than individual features or services.
    - - Constraints on the system from the domain of operation
      - Domain requirements are derived from the application domain of the system rather than from the specific
        
        needs of system users. They may be new functional requirements in their own right, constrain existing
        
        functional requirements, or set out how particular computations must be carried out.
    - - Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
      - May state what the system should not do.
  - - - Introduction
        
        Functional user requirements may be high-level statements of what the system should do.
        
        Functional system requirements should describe the system services in detail.
        
        Depend on the type of software, expected users and the type of system where the software is used.
        
        A business process the system has to perform
        
        Describe functionality or system services.
        
        Information the system must contain
      - Requirements imprecision
        
        Problems arise when requirements are not precisely stated.
        
        Ambiguous requirements may be interpreted in different ways by developers and users.
        
        Example: search
        
        User intention
        
        – search for a patient name across all appointments in all clinics;
        
        Developer interpretation
        
        – search for a patient name in an individual clinic. User chooses clinic then search.
      - Requirements completeness and consistency
        
        Complete
        
        They should include descriptions of all facilities required.
        
        Consistent
        
        There should be no conflicts or contradictions in the descriptions of the system facilities.
        
        In principle, requirements should be both complete and consistent.
        
        In practice, it is impossible to produce a complete and consistent requirements document.
    - - Introduction
        
        Process requirements may also be specified mandating a particular IDE, programming language or development method.
        
        Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
        
        These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.
      - Non-functional requirements implementation
        
        influence
        
        For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components.
        
        Non-functional requirements may affect the overall architecture of a system rather than the individual components.
        
        It may also generate requirements that restrict existing requirements.
        
        A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required.
      - Classifications
        
        Teacher said
        
        Operational - Môi trường vận hành
        
        Security - bảo mật
        
        Performance - Hiệu năng
        
        Cultural and Political - Văn hóa công ty và chính sách pháp luật
        
        Text book
        
        Organisational requirements
        
        Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
        
        External requirements
        
        Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
        
        Product requirements
        
        Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
      - Goals and Requirements
        
        Verifiable non-functional requirement
        
        A statement using some measure that can be objectively tested.
        
        Goal
        
        A general intention of the user such as ease of use.
        
        Goals are helpful to developers as they convey the intentions of the system users.
        
        Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.
      - Metric
        
        Size
        
        Speed
        
        Ease of use
        
        Reliablility
        
        Robustness
        
        Portability
      - Usability requirements
        
        The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. (Goal)
        
        Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use. (Testable non-functional requirement)
    - - Introduction
        
        Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.
        
        The system’s operational domain imposes requirements
        on the system.
        
        If domain requirements are not satisfied, the system may
        be unworkable.
      - Problems
        
        Understandability
        
        Requirements are expressed in the language of the application
        domain;
        
        This is often not understood by software engineers developing
        the system.
        
        Implicitness
        
        Domain specialists understand the area so well that they do not
        think of making the domain requirements explicit.
- - - - Characteristics
        
        Requirements are written as natural language sentences
        supplemented by diagrams and tables.
        
        Used for writing requirements because it is expressive, intuitive and universal. This means that the requirements can be understood by users and customers.
      - Problems
        
        Lack of clarity
        
        Requirements confusion
        
        Functional and non-functional requirements tend to be mixed-up.
        
        Requirements amalgamation
        
        Several different requirements may be expressed together.
  - - - requirements should state what the system
        should do
      - and the design should describe how it does
        this.
    - - A system architecture may be designed to structure the
        requirements;
      - The system may inter-operate with other systems that generate
        design requirements;
      - The use of a specific architecture to satisfy non-functional
        requirements may be a domain requirement.
      - This may be the consequence of a regulatory requirement.
- - - - Groups related requirements and organises them into coherent
        clusters.
    - - Prioritising requirements and resolving requirements conflicts.
    - - Interacting with stakeholders to discover their requirements.
        Domain requirements are also discovered at this stage.
    - - Requirements are documented and input into the next round of
        the spiral.
  - - - Systems normally have a range of stakeholders.
      - The process of gathering information about the required and existing systems and distilling the user and system requirements from this information.
      - Interaction is with system stakeholders from managers to
        external regulators.
    - - Interviewing
      - Scenarios
      - Use cases
      - Ethnography
- - - - Are all functions required by the
        customer included?
    - - Can the requirements be implemented given
        available budget and technology
    - - Are there any requirements conflicts?
    - - Can the requirements be checked?
    - - Does the system provide the functions which
        best support the customer’s needs?
  - - - Introduction
        
        Systematic manual analysis of the requirements
        
        Regular reviews should be held while the requirements
        definition is being formulated.
        
        Both client and contractor staff should be involved in
        reviews.
        
        Reviews may be formal (with completed documents) or
        informal.
      - Check
        
        Traceability
        
        Is the origin of the requirement clearly stated?
        
        Adaptability
        
        Can the requirement be changed without a large impact on other
        requirements?
        
        Comprehensibility
        
        Is the requirement properly understood?
        
        Verifiability
        
        Is the requirement realistically testable?
    - - Using an executable model of the system to check requirements.
        Covered in Chapter 2
    - - Developing tests for requirements to check testability
- - - - Traceability policies
        
        These policies define the relationships between each requirement and between the requirements and the system design that should be recorded.
      - Requirements identification
        
        Each requirement must be uniquely
        identified so that it can be cross-referenced with other requirements.
      - Tool support
        
        Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.
      - 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.
  - - - The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change.
    - - The requirements document and, where necessary, the system design and implementation, are modified. Ideally, the document should be organized so that changes can be easily implemented.
    - - During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request.
- - - - This is inevitable as requirements may serve a dual function
      - May be the basis for a bid for a contract - therefore must be open to interpretation;
      - May be the basis for the contract itself - therefore must be defined in detail;
    - - Both these statements may be called requirements.A statement of:
      - what the system must do
      - what characteristics the system must have
  - - - Statements in natural language plus diagrams of the services the system provides and its operational constraints.
      - Written for customers.
    - - A structured document setting out detailed descriptions of the system’s functions, services and operational constraints.
      - Defines what should be implemented so may be part of a contract between client and contractor.