Skip to content

Requirements Engineering

  • Software requirement is a condition needed by a user to solve problem or achieve an objective
  • should be clear, correct and well-defined

  • It is the process of defining, documenting and maintaining requirements in the design process

  • Types of Requirements

    1. Functional Requirements
      • related to functional/working aspects of software
      • Example -> Authentication, business rules, audit tracking, certification requirements, etc.
      • Most common way of giving functional requirements is documenting as plain text
      • Diagrams, use Cases, models prototypes, etc. are also formats of preparing functional requirements
      • These are Mandatory! Important for system operation
      • Describes What the product does
      • Functional Testing is here -> API testing, system, integration, etc.
    2. Non-functional Requirements
      • Are not related to the software's functional aspect./
      • The expected characteristics of target software
      • Examples, Security, Storage, Configuration, Performance, Cost, disaster recovery, Flexibility, Interoperability, Accessibility, etc.
      • Two sub-types
        • Execution Qualities
          • observable at runtime -> Security and usability
        • Evolution Qualities
          • Statically Observable
          • testability, maintainability, extensibility and scalability
      • These specify the quality attribute of the software
      • Describes the working of the product
      • Non-functional testing such as usability, performance, stress, security, etc.
      • Not mandatory | Not important for system operation but may be desirable.

  • Requirements: User vs SystemuserVsSystemRequirements.png

  • Establishing Groundwork

  • Identifying Stakeholders
    • Any person who benefits directly or indirectly from the system being developed is a stakeholder.
  • Recognising multiple viewpoints
    • As information is gathered from multiple viewpoints, collecting requirements may be inconsistent
  • Working Towards Collaboration
    • n stakeholders may have n different opinions on the requirements
    • Customers must work together with software development team to create a successful system
  • Asking the first questions
    • For identifying stakeholders
      • Who is requesting the project?
      • who will be using the solution?
      • economic value of the solution?
    • Understanding Problems and Solution
      • to help gain a better understanding of problem and to allow the customer to express his or her thoughts on a solution
Requirements Engineering
  • The process of collecting the software requirements from the client and then understanding, analysis, and documenting it is called requirement engineering
  • Requirement Engineering consists of seven different tasks:
  • Inception -> asks a set of questions to establish software process
  • Elicitation -> requirement gathering from stakeholders
    • Possible problems of scope, understanding and volatility between customers and developers
  • Elaboration
  • Negotiation
  • Specification
  • Validation
  • Management
Requirements Engineering Process
# Feasibility Study
  • The goal is to decide whether to take the project or not
  • Technical Feasibility: Evaluates the current technologies, which are needed to achieve customer requirements within the time and budget.
  • Operational Feasibility: Required software solve business problems and customer requirements.

  • Economic Feasibility: It decides whether the necessary software can generate financial profits for an organization.

  • Requirement Elicitation & Analysis

    • Techniques of Requirements Elicitation:
      • Interviews
      • Surveys
      • Focus Groups
      • Observation
      • Prototyping
  • Software Requirements Specification(SRS) defines
    • How the intended software will interact with hardware.
    • External interface / GUI
    • Speed of operation, Response time of system
    • Portability of software across various platforms
    • Maintainability
    • Speed of recovery after crashing
    • Security, Quality. Limitations etc.
  • Software Requirement Validation
    • the requirements discussed in SRS are validated or tested
    • checked if they are practically implementable, correctness as per functionality and software, existence of ambiguity, any changing/additional requirement
  • Software Requirement Management
      1. Tracking & Controlling Changes: Handling changing requirements from customers.
    2. Version Control: Keeping track of different versions of system.
    3. Traceability: Trace to software is design, develop or test as per requirements or not.
    4. Communication: If changing requirements has any issues contact with clients within time.
    5. Monitoring & Reporting: Monitoring development process & report the status.
SRS Template
![[SRS Template.png]]

  • Characteristics of a good SRS

    1. Correctness
    2. Completeness
    3. Consistency
    4. Unambiguous
    5. Ranking for importance and stability (For specific priority requirements)
    6. Modifiability
    7. Verifiability
    8. Traceability
    9. Design Independence
    10. Testability
    11. Understandable by the customer
    12. The right level of abstraction

  • A data model is an abstract view of the data referred to in the product being developed.

  • Types of Data Model
    1. Conceptual Data Model -> front view of the of each data entity
    2. Logical Data Model -> etailed description of each data entity their attributes & relationships between entities
    3. Physical Data Model -> layout of the actual database with all its components
Data Modeling Techniques
  1. Object Oriented
  2. Entity Relationship -> System representation at very High level
  3. Network -> More advance than hierarchical | a child can have multiple parent nodes
  4. Relational ->
  5. Hierarchical -> single root node, tree like structure