Requirement Engineering Chapter 4

• Chapter 4 focuses on requirement engineering

Overview

• Primary topics include functional and non-functional requirements, engineering processes, requirements elicitation, specification, validation, and change management
• Requirement engineering establishes customer-required services and operational constraints
• System requirements describe system services and constraints produced during the engineering process

Requirements Types

• It ranges from abstract service statements to detailed functional specs
• Inevitable because requirements serve two purposes: contract bids (open interpretation) and contract basis (detailed definition)
• Requirements abstraction entails companies defining needs abstractly for contractor bids; contractors then write detailed system definitions for clients
• User specifications employ natural language and diagrams for customer understanding
• System specifications are structured documents detailing functions of the system, which may be part of a client-contractor agreement

Requirements Readers and Stakeholders

• User requirements are intended for client managers, end-users, client engineers, system architects, and contractor managers
• System requirements primarily target system end-users, client engineers, system architects, and software developers
• System stakeholders are individuals or groups affected by the system and have a legitimate interest
• Stakeholder categories include end-users, system managers, system owners, and external entities.

Agile Methods

• Agile methods view comprehensive system specifications as inefficient due to rapid changes
• Agile focuses on incremental engineering using user stories, suitable for business systems yet challenging for pre-delivery or multi-team projects

Functional vs Non-Functional Requirements

• Functional requirements describe what the system should do, its response to inputs, and its behavior in particular situations, and what not to do
• Non-functional requirements impose constraints on services, such as timing, development process, standards and apply to the entire system
• Domain requirements are operational constraints
• Functional requirements describe system services, depending on software type, expected users, and usage context. They range from high-level user needs(functional USER requirements and detailed system features(functional SYSTEM requirements)
• Ambiguity in functional requirements can lead to interpretation issues between developers and users
• System requirements should be complete including all required facilities and consistent with no conflicts
• Business complexity can make it impossible to produce a complete and consistent requirements document
• Non-functional requirements define system properties (e.g., reliability) and may mandate specific development tools or methods
• Failure to meet non-functional criteria can render the system unusable
• Types of non-functional requirements include product, organizational, and external requirements

Non-Functional Requirements Implementations and Classificatons

• They can shape overall system architecture and generate related functional requirements.
• Classifications:
  • Product requirements
    • Specify how the delivered product ought to behave, such as its execution speed and reliability
  • Organizational requirements
    • Stem from organizational protocols, for example, process standards and implementation mandates
  • External requirements
    • Emerge from outside influences like cross-system operability mandates

Goals

• Goals may provide insights to developers regarding user requirements that could be difficult to state precisely
• Verifiable requirements should have statements using measures for testability
• Usability goals example
  • The system should be easy to use by medical staff and organized to minimize user errors
• Non-functional metrics include:
  • Speed
    • Measured by transactions / second
  • Ease of use
    • Measured by training time

Requirement Engineering Processes and Elicitation

• They vary based on project specifics, generic activities include elicitation, analysis, validation, and management
• Requirements Elicitation involves finding out about the application domain and operational constraints, which can involve a range of stake holders
• In practice, RE is an iterative activity in which processes are interleaved
• The stages of elicitation include discovery, classification, prioritization, and specification

Requirement Elicitation Problems

• Stakeholder communication issues during the analysis process and new stakeholder's opinions
• The requirements change during the analysis process
  • New stakeholders may emerge and the business environment may change

Process Activites

• Requirements Classification and Organization
  • Requirements are related to and organized into coherent clusters
• Prioritisation and negotiation
  • Prioritising requirements and resolving requirements conflicts
• Requirements specification -Requirements are documented and input into the next round of the spiral*
• Requirements Discovery
  • Gather information about existing systems and stakeholders

Interviews

• Interviews are frequently used in RE processes, can be;
  • Closed
    • Based on pre-determined questions
  • Open
    • Explored with stakeholders
• Can involve application specialists creating difficulties for requirement engineers

Ethnography and Focused Ethnography

• A social scientist spends a considerable time observing and analyzing how people actually work
• Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models
• It is effective for understanding existing processes but cannot identify new features to add to a system
• Focused ethnography combines ethnography with prototyping where prototype development results in unanswered questions which focus the ethnographic analysis
• Focused Ethnography was was developed in a project studying the air traffic control process
• The problem with ethnography is that it studies existing practices which may have some historical basis which is longer relevant

Stories and Scenarios

• Scenarios and user stories describe system use in real-life examples and in a particular task
• Stakeholders can relate to scenarios leading to useful feedback discussions.
• Scenarios should have: - 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 Specification

• Process involves documenting user and system requirements in a software requirements documents
• The user needs to be able to understand the software by end-users
• Important for the requirements to be complete as possible
• Should define WHAT the system should do rather than HOW it should do it (i.e. it is NOT a design document)

Ways of Writing Specifications

• Include natural language and Structured language.
• Natural language specification
  • Used for writing requirements because it is expressive, intuitive and universal for all individuals, diagrams and tables
  • Requires a standardized format that specifies 'shall' for mandatory ones or 'should' for desirable ones
  • Can have problems like clarity, confusion or amalgmation
• Structured language:
  • Form-based specifications including a definition of inputs and outputs, functions of the business processes.
• Tabular specifications
  • Useful for defining multiple potential courses of action or processes.
  • For example, the insulin pump systems bases its computations on the rate of change of blood sugar level

Use Cases

• Use-cases are a kind of scenario that are included in the UML
• Use cases identify the actors in an interaction and which describe the interaction itself
• Important a set of use cases describe all possible interactions with the system

The Software Requirements Document

• The Official statement of what is required from developers
• Includes -User requirements
  • System requirements
• Not a design document rather focus on WHAT not HOW
• User of requirements system includes specifying requirements, planning bids, planning, understanding the system, developing validation tests and maintain the system

Requirements Validation

• Validation addresses if the requirements properly define what the customer needs
• Undetected errors can cost up to 100x more post-delivery than fixing implementation bugs
• Checking includes validity(functions supporting customer needs), consistency(conflict free), realism(can implement within tech constraints), completeness (are customer functions included?) and verifiability (can it be tested?)
• Validation Techniques includes the systematic manual analysis of specifications
• Using Prototyping and the development of test for requirements to check testability
• During review, the requirements need to be be verifiable, comprehensible, traceable for its origins and adaptable for any requirement changes that could impact system functionality

Requirements Change

• Business and tech environments evolve post-installation, change often derives the requirement
• System patrons and actual system users are distinctly different
• Large, diverse user bases can have conflicting needs
• Change analysis and costing should be undertaken with a focus on traceability and impact of system requirements before decisions can be made about whether to implement requirements change

Requirements Management Planning

• It establishes the detail that is required, like requirements and change management, traceability and tool support as well as the design that should be recored.