Requirements engineering is a crucial activity in software development, as it defines what the

system should do without specifying how it will be done. It involves several process steps:

1. Requirements Elicitation: Also known as gathering of requirements, this step

involves identifying requirements with the help of customers and existing systems
processes.
2. Requirements Analysis: Analysis of requirements starts with requirement elicitation.
The requirements are analyzed to identify inconsistencies, defects, omissions, etc.
Requirements are described in terms of relationships and conflicts are resolved.
3. Requirements Documentation: This is the end product of requirements elicitation
and analysis. The documentation is crucial as it forms the foundation for the design of
the software. The document is known as the Software Requirements Specification
(SRS).
4. Requirements Review: The review process is carried out to improve the quality of
the SRS. It may also be called requirements verification. Review and verification
should be treated as a continuous activity that is incorporated into the elicitation,
analysis, and documentation processes.

The quality of a software product is dependent on the quality of the requirements engineering
process. Without well-written requirements specifications, developers do not know what to
build, customers do not know what to expect, and there is no way to validate that the built
system satisfies the requirements. Requirements engineering is the disciplined application of
proven principles, methods, tools, and notations to describe a proposed system's intended
behavior and its associated constraints.

There are several types of requirements in software engineering:

1. Known Requirements: These are requirements that stakeholders are aware of and
believe should be implemented in the software.
2. Unknown Requirements: These are requirements that stakeholders have forgotten
about or do not currently need, but may be needed in the future or by another
stakeholder.
3. Undreamt Requirements: These are requirements that stakeholders may not be able
to think of due to limited domain knowledge or imagination.

Requirements can also be classified based on their nature:

1. Functional Requirements: These describe what the software should do, often
referred to as product features.
2. Non-functional Requirements: These are quality requirements that specify how well
the software should perform its functions. They include performance, availability,
reliability, usability, maintainability, portability, and testability.
Requirements Elicitation in Software Engineering

Requirements elicitation is the crucial process of gathering and defining the requirements for
a software system. Its goal is to ensure that the software development process is founded on a
clear and comprehensive understanding of the customer’s needs and requirements. This
process involves various techniques to gather, analyze, document, and validate these
requirements. Effective requirements elicitation lays the foundation for successful software
development by aligning the final product with the customer's expectations.

Requirement Elicitation Methods

1. Interviews

The objec ve of conduc ng an interview is to understand the customer’s expecta ons of the
so ware.
It is impossible to interview every stakeholder hence representa ves from groups are selected based
on their exper se and credibility. Interviews may be open-ended or structured.

1. In open-ended interviews, there is no pre-set agenda. Context-free ques ons may be asked
to understand the problem.

2. In a structured interview, an agenda of fairly open ques ons is prepared. Some mes a
proper ques onnaire is designed for the interview.

2. Brainstorming Sessions

 Brainstorming Sessions is a group technique

 It is intended to generate lots of new ideas hence providing a pla orm to share views

 A highly trained facilitator is required to handle group bias and conflicts.

 Every idea is documented so that everyone can see it.

 Finally, a document is prepared which consists of the list of requirements and their priority if
possible.

3. Facilitated Applica on Specifica on Technique

Its objec ve is to bridge the expecta on gap – the difference between what the developers think
they are supposed to build and what customers think they are going to get. A team-oriented
approach is developed for requirements gathering. Each a endee is asked to make a list of objects
that are:

1. Part of the environment that surrounds the system.

2. Produced by the system.

3. Used by the system.

Each par cipant prepares his/her list, different lists are then combined, redundant entries are
eliminated, the team is divided into smaller sub-teams to develop mini-specifica ons and finally, a
dra of specifica ons is wri en down using all the inputs from the mee ng.

4. Quality Func on Deployment

In this technique customer sa sfac on is of prime concern, hence it emphasizes the requirements
that are valuable to the customer.
3 types of requirements are iden fied:

 Normal requirements: In this the objec ve and goals of the proposed so ware are discussed
with the customer. For example – normal requirements for a result management system may
be entry of marks, calcula on of results, etc.

 Expected requirements: These requirements are so obvious that the customer need not
explicitly state them. Example – protec on from unauthorized access.

 Exci ng requirements: It includes features that are beyond customer’s expecta ons and
prove to be very sa sfying when present. For example – when unauthorized access is
detected, it should back up and shut down all processes.

5. Use Case Approach

Use Case technique combines text and pictures to provide a be er understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a func onal view
of the system.
The components of the use case design include three major things – Actor, use cases, and use case
diagram.

1. Actor: It is the external agent that lies outside the system but interacts with it in some way.
An actor may be a person, machine, etc. It is represented as a s ck figure. Actors can be
primary actors or secondary actors.

 Primary actors: It requires assistance from the system to achieve a goal.

 Secondary actor: It is an actor from which the system needs assistance.

2. Use cases: They describe the sequence of interac ons between actors and the system. They
capture who(actors) do what(interac on) with the system. A complete set of use cases
specifies all possible ways to use the system.

3. Use case diagram: A use case diagram graphically represents what happens when an actor
interacts with a system. It captures the func onal aspect of the system.

 A s ck figure is used to represent an actor.

  An oval is used to represent a use case.

 A line is used to represent a rela onship between an actor and a use case.

Requirements Analysis

Requirements analysis is a crucial activity following elicitation, where gathered requirements

are refined and scrutinized for consistency and clarity. This process enhances the
understandability of the project significantly. Here are the steps involved:

1. Draw the Context Diagram:

o Defines boundaries and interfaces of the proposed system with the external
world.
o Identifies entities outside the system that interact with it.
o Example: Context diagram for a student result management system.
2. Develop Prototypes (Optional):
o Constructing a prototype can help understand what the customer really wants.
o Prototypes look and act like parts of the system to gather feedback for
continuous improvement.
o Useful when there's uncertainty about requirements.
3. Model the Requirements:
o Consists of graphical representations of functions, data entities, external
entities, and their relationships.
o Helps find incorrect, inconsistent, missing, and superfluous requirements.
o Examples include data flow diagrams, entity relationship diagrams, data
dictionaries, and state-transition diagrams.
4. Finalize the Requirements:
o After modeling, there's a better understanding of the system's behavior.
o Inconsistencies and ambiguities are identified and corrected.
o Data flow among modules is analyzed.
o Elicitation and analysis provide better insight into the system, leading to
finalizing the analyzed requirements.

The final step is to document these requirements in a prescribed format, usually the Software
Requirements Specification (SRS), which acts as the foundation for the development phase.

Data Flow Diagrams (DFDs) are essential tools in software engineering for
visualizing the flow of data within a system. Here's a breakdown of key points about DFDs:

1. Purpose: DFDs model the flow of data within a system, representing how inputs and
outputs are processed without specifying the exact implementation details.
2. Components:
o Processes: Represented by circles or bubbles, processes transform input data
into output data.
o Data Flows: Represented by arrows, data flows show the movement of data
between processes, data stores, and external entities.
o Data Stores: Represented by parallel lines, data stores are repositories where
data is stored for later use.
 o Sources or Sinks: Represented by squares, sources or sinks are external
entities that act as sources of inputs or destinations of outputs for the system.
3. Rules and Guidelines:
o Names should be unique for easy reference.
o DFDs do not imply an order of events; they show data flow.
o Avoid using decision points or diamond-shaped boxes, as they imply an
ordering of events.
o Defer error conditions and error handling details until later stages of analysis.’

Data Dictionary (DD) is a key tool for managing the complexity of Data Flow
Diagrams (DFDs) by providing a detailed repository of information about data items defined
in the DFDs. Here's a breakdown of key points about data dictionaries:

1. Purpose: Data dictionaries serve as repositories to store information about data items
defined in DFDs, ensuring that both customers and developers use the same
definitions and terminologies.
2. Information Included:
o Name of the data item
o Aliases (other names for the item)
o Description/purpose
o Related data items
o Range of values
o Data structure definition/form
3. Usage:
o Name: Self-explanatory name of the data item.
o Aliases: Other names by which the data item is known.
o Description/Purpose: Textual description of the data item's use or purpose.
o Related Data Items: Relationships between data items.
o Range of Values: Possible values for the data item.
 o Data Structure Definition/Form: Physical structure or composition of the
data item.
4. Mathematical Operators (Table 3.3):
o x=a+b: x consists of data elements a and b.
o x = [a|b]: x consists of either data element a or b.
o x=a: x consists of an optional data element a.
o x = y{a}: x consists of y or more occurrences of data element a.
o x = {a}z: x consists of z or fewer occurrences of data element a.
o x = y{a}z: x consists of some occurrences of data element a which are
between y and z.
5. Benefits:
o Create an ordered listing of all data items.
o Create an ordered listing of a subset of data items.
o Find a data item name from a description.
o Design software and test cases.

Overall, data dictionaries play a crucial role in ensuring clear communication and
understanding of data elements in a system, aiding in the development and testing processes.

Entity-Relationship Diagrams (ERDs) are an important tool in software

engineering for modeling the data within an organization. Here's a breakdown of key points
about ERDs:

1. Purpose: ERDs provide a detailed logical representation of the data for an

organization, focusing on entities, relationships, and attributes.
2. Entities:
o An entity is a fundamental thing in an organization about which data is
maintained.
o Each entity has its own identity, distinguishing it from other entities.
o Entity types describe all entities with a common definition, relationships, and
attributes.
o Entities are represented by rectangles in an ER diagram, with the entity name
inside.
3. Relationships:
o Relationships associate two or more entity types.
o Binary relationships involve two entity types, while ternary relationships
involve three.
o Relationships are represented by diamond notation in ER diagrams,
connecting the related entities.
4. Degree of Relationships:
o The degree of a relationship is the number of entity types that participate in it.
o Unary relationships involve instances of one entity type, while binary
relationships involve two, and ternary involve three.
5. Cardinalities and Optionality:
o Cardinality refers to the number of instances of one entity that can be
associated with each instance of another entity in a relationship.
o Cardinalities can be one-to-one, one-to-many, or many-to-many.
o Optionality indicates whether an entity is a mandatory participant (minimum
cardinality of one) or optional (minimum cardinality of zero).
6. Attributes:
 oAttributes are properties or characteristics of entities.
oEach entity type has a set of attributes associated with it, defining the
information that can be stored for each entity.
o Attributes are represented by ellipses in an ER diagram, connected to the
associated entity.
7. Candidate Keys and Identifiers:
o Every entity type must have a candidate key, which uniquely identifies each
instance of the entity.
o An identifier is a selected candidate key used as the unique characteristic for
an entity type.

ERDs are valuable for understanding the structure of data within an organization and are
often used in conjunction with other analysis techniques, such as data flow diagrams, to
provide a comprehensive view of the system.

Software Prototyping is the technique of constructing a partial implementation of a

system to gather feedback from customers, users, or developers. There are two main
approaches to software prototyping:

1. Throwaway Prototyping: This approach involves building a prototype to learn about

the problem or solution, with the intention of discarding it after the required
knowledge is gained. It is used to explore and criticize proposed systems before full-
scale development. The focus is on functionality demonstration and system growth.
2. Evolutionary Prototyping: In this approach, the prototype is built in successive steps
to learn about the problem or solution. The prototype evolves into the final system as
more knowledge is gained and the system is adapted to meet the needs. It focuses on
achieving functionality for demonstrating a portion of the system to the end user for
feedback and system growth.

Software Requirements Specification (SRS)

Definition: The Software Requirements Specification (SRS) is a document that describes the
software product to be developed. It outlines the functional and non-functional requirements
of the software system.

The characteristics of a good Software Requirements Specification (SRS)

are crucial for ensuring that the document effectively captures the requirements of the
software system. Here are the key characteristics:

1. Correctness: Every requirement in the SRS should accurately reflect what the
software will do. Errors or inaccuracies in requirements can lead to incorrect software.
2. Unambiguous: Each requirement should have only one interpretation to avoid
confusion. Ambiguous requirements can lead to misunderstandings and errors in
development.
3. Completeness: The SRS should include all significant requirements related to
functionality, performance, design constraints, attributes, or external interfaces. It
should also define the software's responses to all possible inputs and situations.
 4. Consistency: There should be no conflicts or contradictions between different
requirements in the SRS. Consistency ensures that the software behaves predictably
and correctly.
5. Ranked for Importance and/or Stability: Each requirement should be ranked based
on its importance or stability. This helps prioritize requirements and focus on essential
aspects of the software.
6. Verifiable: Every requirement should be verifiable, meaning there should be a way to
check that the software meets the requirement. Non-verifiable requirements should be
avoided.
7. Modifiable: The SRS should be structured in a way that allows for easy and
consistent changes to requirements. This ensures that the document remains up-to-
date throughout the software development process.
8. Traceable: Each requirement should be traceable to its origin and should facilitate
referencing in future development or enhancement documentation. Traceability helps
in managing changes and understanding the impact of modifications.

Organization of Software Requirements Specification (SRS)

The Institute of Electrical and Electronics Engineers (IEEE) provides guidelines for
organizing an SRS document. While different projects may require different organizational
structures, the general organization of an SRS includes the following sections:

1. Introduction
o Purpose: Identify the purpose of the SRS and its intended audience.
o Scope: Describe the software product(s) to be produced, including what the
software will and will not do.
o Definitions, Acronyms, and Abbreviations: Provide definitions for terms
used in the SRS.
o References: List all documents referenced in the SRS.
o Overview: Describe the contents of the SRS and how it is organized.
2. The Overall Description
o Product Perspective: Describe how the software fits into the larger system, if
applicable.
o Product Functions: Summarize the major functions of the software.
o User Characteristics: Describe the general characteristics of the intended
users.
o Constraints: Describe any limitations or constraints on the software.
o Assumptions and Dependencies: List factors that affect the requirements
stated in the SRS.
3. Specific Requirements
o External Interfaces: Describe inputs into and outputs from the software
system.
o Functions: Define the fundamental actions that the software must perform.
o Performance Requirements: Specify numerical requirements for
performance.
o Logical Database Requirements: Specify requirements for information
placed into a database.
o Design Constraints: Specify design constraints imposed by standards,
hardware limitations, etc.
 o Software System Attributes: Specify quality attributes of the software, such
as reliability and maintainability.
o Organizing the Specific Requirements: Organize requirements based on
system mode, user class, objects, features, stimulus, response, or functional
hierarchy.
4. Change Management Process: Identify the process for managing changes to the
SRS.
5. Document Approvals: Identify the approvers of the SRS document.
6. Supporting Information: Include a table of contents, index, and appendices if
necessary.

Appendices may include sample I/O formats, cost analysis studies, user survey results, or
other supporting information.

Requirement review is a crucial step in the so ware development process that ensures the
completeness, correctness, and consistency of the requirements before moving forward with design
and implementa on.

 Plan the Review:

 Identify stakeholders and participants for the review.

 Determine the review objectives and criteria.
 Establish a timeline and schedule for the review process.
 Prepare review materials, including the SRS document and any relevant guidelines or
checklists.

 Distribute the SRS:

 Send the SRS document to all stakeholders and participants.

 Ensure that everyone has access to the necessary review materials and tools.

 Read the Document:

 Stakeholders and participants should carefully read the SRS document, paying
attention to detail and noting any questions or concerns.

 Organize a Review Meeting:

 Schedule a meeting with stakeholders and participants to discuss the SRS document.
 Ensure that the meeting is well-organized and that all necessary parties are present.

 Follow-Up Action:

 After the review meeting, compile feedback and comments from stakeholders.
 Address any issues or concerns raised during the review process.
 Communicate updates or changes to the SRS document to all stakeholders.

 Revise the SRS Document:

 Incorporate feedback and revisions into the SRS document.
 Ensure that the document is updated to reflect any changes made during the review
process.
 Distribute the revised SRS document to all stakeholders and participants.