SOFTWARE

ENGINEERING
Ahtiqa Tabassum
Lecture 6
Requirement Engineering
The process of finding out, analyzing,
documenting and checking these
services and constraints is called
requirements engineering (RE).
 Functional Requirements
Requirements, which are related to functional aspect of software fall into
this category.
They define functions and functionality within and from the software
system.

Examples -
● Search option given to user to search from various invoices.
● User should be able to mail any report to management.
● Users can be divided into groups and groups can be given separate
rights.
● Should comply business rules and administrative functions.
● Software is developed keeping downward compatibility intact.
 Non-Functional Requirements
Requirements, which are not related to functional aspect of software.
They are implicit or expected characteristics of software, which users
make assumption of.

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility
• downward compatibility intact.
Requirements Engineering
Process
Requirements Engineering Process

01 Feasibility Study

02 Requirements Elicitation

03 Requirement Specification

04 Requirement Validation & Verification

05 Requirements Management
Types of Non-Functional
Requirements
 Feasibility Study
A feasibility study assesses the practicality and viability of a proposed software
project. It helps determine if the project is worth pursuing by evaluating
various factors.

● Technical Feasibility: Evaluates whether the project can be developed with

the current technology and resources available.
● Economic Feasibility: Analyzes if the project is cost-effective and fits within
the budget constraints.
● Legal Feasibility: Considers any legal constraints or regulations that may
impact the project.
● Operational Feasibility: Assesses whether the system can operate effectively
within the existing environment and processes.
● Schedule Feasibility: Determines if the project can be completed
within a reasonable timeframe.
 Requirements Elicitation
Requirements elicitation is the process of gathering requirements from
stakeholders to understand what the software must do. It is crucial for
collecting accurate and comprehensive needs.

Techniques:
● Interviews: Conducting one-on-one discussions with users and customers
to gather detailed information.
● Surveys and Questionnaires: Collecting data from a larger audience to
understand their needs and preferences.
● Workshops: Organizing collaborative sessions to brainstorm and discuss
requirements with stakeholders.
● Observation: Observing users in their environment to identify needs and
workflows.
● Document Analysis: Reviewing existing documentation and regulations to
gather relevant requirements.
 Requirements Specification
Requirements specification is the process of documenting the collected
requirements in a clear, unambiguous, and complete manner, ensuring all
stakeholders have a shared understanding.

Formats:
● Natural Language Documents: Detailed descriptions of requirements
written in plain language.
● Use Case and User Story Descriptions: Defining interactions between users
and the system to illustrate requirements.
● Functional and Non-Functional Requirements: Specifying what the system
should do (functional) and how it should perform (non-functional).
● Supplementary Diagrams: Using visual aids like use case diagrams to
enhance understanding.
 Software Requirements Specification
➜ How do we communicate the Requirements to others?
 It is common practice to capture them in an SRS
➢ But an SRS doesn’t need to be a single paper document...

➜ Audience
➜ Purpose
 Customers & Users
 Communication ➢ interested in system requirements…
➢ explains the application domain and the system
➢ …but not detailed software requirements
to be developed
 Systems (Requirements) Analysts
 Contractual
➢ Write other specifications that inter- relate
➢ May be legally binding!
 Developers, Programmers
➢ Expresses agreement and a commitment
➢ Have to implement the requirements
 Baseline for evaluating the software
 Testers
➢ supports testing, V&V
➢ Have to check that the requirements have
➢ “enough information to verify whether
been met
delivered system meets requirements”
 Project Managers
 Baseline for change control
➢ Have to measure and control the project
 Typical mistakes
• Noise • Requirements on users
➢ text that carries no relevant information to any ➢ Cannot require users to do certain things, can
feature of the problem. only assume that they will
• Silence • Jigsaw puzzles
➢ a feature that is not covered by any text. ➢ distributing key information across a document
• Over-specification and then cross-referencing
➢ text that describes a detailed design decision, • Duckspeak requirements
rather than the problem. ➢ Requirements that are only there to conform
• Contradiction to standards
➢ text that defines a single feature in a number of • Unnecessary invention of terminology
incompatible ways. ➢ E.g. ‘user input presentation function’
• Ambiguity • Inconsistent terminology
➢ text that can be interpreted in at least two ➢ Inventing and then changing
different ways. terminology
• Forward reference • Putting the onus on the developers
➢ text that refers to a terms or features yet to be ➢ i.e. making the reader work hard to decipher
defined. the intent
• Wishful thinking • Writing for the hostile reader
➢ text that defines a feature that cannot possibly ➢ There are fewer of these than friendly
be verified. readers
 SRS Contents
➜ Software Requirements Specification should address:
• Functionality.
➢ What is the software supposed to do?
• External interfaces.
➢ How does the software interact with people, the system's hardware, other hardware, and
other software?
➢ What assumptions can be made about these external entities?
• Required Performance.
➢ What is the speed, availability, response time, recovery time of various software functions, and so
on?
• Quality Attributes.
➢ What are the portability, correctness, maintainability, security, and other considerations?
• Design constraints imposed on an implementation.
➢ Are there any required standards in effect, implementation language, policies for database
integrity, resource limits, operating environment(s) and so on?
 SRS should not include
➜ Project development plans
• E.g. cost, staffing, schedules, methods, tools, etc
➢ Lifetime of SRS is until the software is made obsolete
➢ Lifetime of development plans is much shorter

➜ Product assurance plans

• Configuration Management, Verification & Validation, test plans, Quality Assurance, etc
➢ Different audiences
➢ Different lifetimes

➜ Designs
• Requirements and designs have different audiences
• Analysis and design are different areas of expertise
➢ I.e. requirements analysts shouldn’t do design!
• Exceptwhere applicationdomainconstrainsthe design
➢ e.g. limited communication between different subsystems for security reasons
 Organizing the Requirements
Need a logical organization for the document
● IEEE standard offers different templates
Example Structures - organize by…
● External stimulus or external situation
○ e.g., for an aircraft landing system, each different type of landing situation: wind gusts, no
fuel, short runway, etc
● System feature
○ e.g., for a telephone system: call forwarding, call blocking, conference call, etc
● System response
○ e.g., for a payroll system: generate pay-cheques, report costs, print tax info;
● External object
○ e.g. for a library information system, organize by book type
● User type
○ e.g. for a project support system: manager, technical staff, administrator, etc.
● Mode
○ e.g. for word processor: page layout mode, outline mode, text editing mode, etc
● Subsystem
○ e.g. for spacecraft: command & control, data handling, comms, instruments, etc.
Requirements for Verification and
Validation
Verification and validation requirements ensure that the software meets
specifications and fulfills its intended purpose.

Key Concepts:
● Verification: The process of checking if the product is being built correctly
(i.e., it meets the design specifications).
● Validation: The process of ensuring that the right product is being built (i.e.,
it meets user needs and expectations).

Importance:
● Requirements must be testable to enable effective testing.
● Techniques such as reviews, inspections, and prototyping are used to
confirm requirements.
● Maintaining traceability of requirements to tests ensures that all
requirements are verified and validated.
 Requirements Management
Requirements management involves tracking and controlling changes to
requirements throughout the project lifecycle, ensuring alignment among
stakeholders.

Key Activities:
● Change Control Processes: Establishing procedures for handling changes to
requirements and assessing their impact.
● Traceability Matrices: Creating matrices that link requirements to their
development and testing phases, ensuring all requirements are addressed.
● Version Control: Keeping track of different versions of requirement
documents to manage changes effectively.
● Prioritization and Negotiation: Prioritizing requirements based on
stakeholder needs and negotiating changes as necessary.
● Continuous Communication: Maintaining ongoing communication with
stakeholders to validate and manage requirements throughout the
project.
THANK
YOU!