unit 4

Cards (29)

  • Requirements engineering (RE)

    The activities for determination, documentation, negotiation, and administration of the functions and properties that a system should support or provide
  • Requirements engineering
    • It is not a single, completed activity at the beginning of a software project
    • It takes place in several cycles, or iterations
    • It is usually carried out alongside the project, not only at the beginning
  • Core activities of requirements engineering
    • Elicitation
    • Documentation
    • Validation
    • Management of requirements
  • Requirements elicitation
    1. Determine the system context
    2. Determine sources for requirements
    3. Select suitable elicitation techniques
    4. Apply techniques
  • Requirements documentation
    1. Determine the purpose and target group of the documentation
    2. Select the level of detail and type of model
    3. Document requirements
    4. Check the documentation
  • Requirements validation
    1. Define validation criteria
    2. Select test principles and test techniques
    3. Perform validation and document results
    4. Negotiation of requirements and conflict management
  • Specification
    Technical documentation of the externally relevant requirements, according to which, a software system will be produced
  • Determined business requirements
    Expanded and refined in the specification to include technical requirements
  • Business-technical specification
    Basis for realizing the system (design and implementation) and the basis for the formulation of various test cases
  • Mistunderstandings of or errors in the specification have far-reaching effects
  • Specification
    An extension of the documentation of requirements
  • There is no difference between RE and specification in terms of elicitation or validation techniques
  • Usage of a Specification within Software Development
    1. Determined business requirements are expanded and refined in the specification to include technical requirements
    2. The result is a business-technical specification
    3. Based on the specification, the system design is created and the system is implemented
    4. Test cases are also created based on the specification for the various test levels, in which the software system is tested for compliance with the requirements
  • Mistunderstandings of or errors in the specification have far-reaching effects on the entire project
  • Specification
    • Provides the technically detailed framework for design decisions
    • Does not decide how the system must be constructed internally, but only describes the externally visible system properties
    • The system is a black box of which the internal structure is unknown
  • Specification Elements
    • Data model
    • Business functions
    • Business rules
  • Interfaces
    The parts of a system that are used for communication with users or other systems
  • Properties specified for interfaces
    • Purpose of the interface
    • Technical protocol or rules for communication
    • Data structure of exchanged messages
  • Quality requirements

    Made verifiable through measurable metrics
  • The system must comply with technical and organizational constraints, such as guidelines, standards, laws, and style guides
  • Aspects defined in user interface specifications
    • Contents and structure of individual dialogues
    • Input validation
    • Dialogue flow
  • GUIs are specified both visually and textually
  • Steps for specification of system structure and behavior
    • Identification and specification of functional components
    • Specification of business data models
    • Specification of business rules
    • Specification of technical interfaces for data exchange
  • Components
    Independent software units that can be combined to form a software system based on agreed interfaces with other components
  • Business data models
    Key entities of a business (or business objects) and their inter-relationships are specified and defined uniformly for all parties involved
  • Business rules
    Statements that define or condition a business aspect
  • Software quality
    The degree to which a product or system can be used by specific users to meet their needs to achieve specific goals with effectiveness, efficiency, freedom from risk, and satisfaction in specific contexts of use
  • Quality requirements have a decisive influence on the architecture of the system in development
  • Quality requirements must be specified in such a way that their fulfillment can be proven in tests