Requirement engineering is the key phase in software development that determines what to build and outlines the quality of the final product. It involves discovering, modeling, documenting, and managing requirements through elicitation, analysis, specification, validation, and management processes. The goal is to develop a system requirements specification document that describes required system functionalities at varying levels of detail, from abstract statements to precise mathematical specifications.

1. Requirement Engineering
Unit-2

2. REQUIREMENTS MODELING AND DESIGN
Requirements Engineering-Crucial steps; types of requirements, Requirements
documentation – Nature of SRS, characteristics of a good SRS, Use case diagrams with
guidelines, DFD (level 0, 1 and 2), SRS Structure, Introduction to software design,
Modularity and Function-oriented design.

3. Requirements engineering
• The process of establishing the services that the customer requires from a system and
the constraints under which it operates and is developed.
• Requirement engineering is the key phase in software development which decides
what to build and it provides the outline of the quality of the final product.
• Requirement engineering is the disciplined, process-oriented approach to the
development and management of requirements.
The goal of requirement engineering is to develop and maintain sophisticated and
descriptive ‘System Requirements Specification’ document.

4. What is a Requirement?
A requirement is a detailed, formal description of system functionalities. It specifies a
function that a system or component must be able to perform for customer satisfaction.
It may range from a high-level abstract statement of a service or of a system constraint
to a detailed mathematical functional specification.
IEEE defines a requirement as :
“a condition of capability of a system required by customer to solve a problem or
achieve an objective.”

5. The main issues involved in requirement engineering are
• Discovering the requirements,
• Technical organization of the requirements,
• Documenting the requirements,
• Ensuring correctness and completeness of the requirements,
• Managing requirements that changes over time.

6. Requirement Engineering Process

7. A typical requirement engineering process has two main aspects:
– Requirement development
– Requirement management
– Requirement development includes various activities, such as elicitation, analysis,
specification and validation of requirements.
– Requirement management is concerned with managing requirements that change
dynamically, controlling the baseline requirements, monitoring the commitments
and consistency of requirements throughout software development.

8. 1. Requirements Elicitation
• Requirement elicitation aims to gather requirements from different perspectives to
understand the customer needs in the real scenario.
• The goals of requirement elicitation are to identify the different parties involved in the
project as sources of requirements, gather requirement from different parties, write
requirements in their original form as collected from the parties, and integrate these
requirements.
• The original requirements may be inconsistent, ambiguous, incomplete, and infeasible
for the business.
• Therefore, the system analyst involves domain experts, software engineers, clients, end
users, sponsors, managers, vendors and suppliers, and other stakeholders and follows
standards and guidelines to elicit requirements.

9. Challenges in requirements elicitation
• The main challenges of requirements elicitation are
– Identification of problem scope,
– Identification of stakeholders,
– Understanding of problem, and
– Volatility of requirements.
• Stakeholders are generally unable to express the complete requirement at a time and in
an appropriate language.
• There may be conflicts in the views of stakeholders.
• It may happen that the analyst is not aware of the problem domain and the business
scenario.
• To face these challenges, analyst will follow some techniques to gather the requirements,
which are called as Fact-Finding Techniques or Requirement Elicitation Techniques.

10. Interviewing
– Interview involves eliciting requirements through face to face interaction with clients,
end-users, domain experts, or other stakeholders associated with the project.
– They are conducted to gather facts, verify and clarify facts, identify requirements,
and determine ideas and opinions.
There are two types of interviews: Unstructured interviews and Structured interviews.
– An unstructured interview aims at eliciting various issues related to stakeholders and
the existing business system perspectives. There is no predefined agenda and thus general
questions are asked from the stakeholders.
– A structured interview is conducted to elicit specific requirements and therefore the
stakeholders are asked to answer specific questions.

11. Questionnaires
Questionnaires are used to collect and record large amount of qualitative as well as
quantitative data from a number of people.
A document with pre-defined set of objective questions and respective options is
handed over to all stakeholders to answer, which are collected and compiled.
The system analyst prepares a series of questions in a logical manner, supplemented by
multiple choice answers and instructions for filling the questionnaires.
It provides standardized and uniform responses from people as questions are
designed objectively.

12. Onsite observation
– The system analyst personally visits the client site organization, observes the
functioning of the system, understands the flow of documents and the users of the
system, etc.
– It helps the system analyst to gain insight into the working of the system instead
documentation.
– Through constant observation, the system analyst identifies critical requirements
and their influence in the system development.

13. Prototyping
– Prototyping technique is helpful in situations where it is difficult to discover and
understand the requirements and where early feedback from the customer is
needed.
– An initial version of the final product called prototype is developed that can give
clues to the client to provide and think on additional requirements.
Brainstorming
An informal debate is held among various stakeholders and all their inputs are
recorded for further requirements analysis.

14. Requirements Analysis
In requirement analysis, we analyze stakeholders’ needs, constraints, assumptions,
qualifications, and other information relevant to the proposed system and organize
them in a systematic manner.
It includes various activities, such as classification, organization, prioritization,
negotiation, and modeling requirements.
The draft requirements are analyzed to verify their correctness and completeness
During requirement analysis, models are prepared to analyze the requirements.
During specification, more knowledge about the problem may be required which can
again trigger the elicitation process.
The models used at this stage include ER diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data dictionaries, etc.

15. The following analysis techniques are generally used for the modeling of requirements:
– Structured analysis
– Data-oriented analysis
– Object-oriented analysis
– Prototyping

16. 1. Structured Analysis
• Structured analysis is also referred to as process modeling or data flow modeling.
• It focuses on transforming the documented requirements in the form of processes of
the system.
• During transformation, it follows a top-down functional decomposition process in
which the system is considered a single process and it is further decomposed into
several sub-processes to solve the problem.
Structured Analysis Tools
During Structured Analysis, various tools and techniques are used for system development. They are −
Data Flow Diagrams
Data Dictionary
Decision Trees
Decision Tables
Structured English
Pseudocode

17. Benefits of Structured Analysis
• A data-flow-based structured analysis is easy to present the customer problems in a
pictorial form that can easily be converted into structured design.
• The top-down decomposition approach enables producing a model in an organized
manner.
• The DFD-based approach can be used to support other methodologies.
• It does not require much technical expertise
• It helps to understand the system scope and its boundaries.
• It provides proper communication of system knowledge to the users

18. 2. Data-Oriented analysis
• Data-oriented analysis is also referred to as data-oriented modeling, which aims at
conceptual representation of the business requirements.
• A data model is the abstraction of the data structures required by a database rather than
the operations on those data structures.
• A data model is independent of hardware or software constraints that are used to
implement the database.
• Without analyzing data models, it is not possible to design database.
• Data models ensure that all data objects required by the database are completely and
accurately represented.
• Data models are composed of data entities, associations among different entities, and the
rules which govern operations on the data.
• Data models are accompanied by functional models that describe how the data will be
processed in the system.

19. Entity Relationship Modeling (ERM)
• Entity relationship modeling (ERM) is a pictorial method of data representation.
• ERM is represented by the E-R diagram that represents data and organizes them in such
a graphical manner that helps to design the final database.
• An entity or entity class is analogous to the class in object orientation, which represents
a collection of similar objects.
• An entity may represent a group of people, places, things, events, or concepts.
• For example, student, course, university, fees, etc., represent entities.
• An independent entity or strong entity is one that does not rely on another for
identification.
• A dependent entity or weak entity is one that relies on another for identification

20. 3. Object-Oriented Analysis
• Object-oriented approach also combines both data and processes into single entities
called objects.
• The object-oriented approach has two aspects, object-oriented analysis (OOA) and
object oriented design (OOD).
• The idea behind OOA is to consider the whole system as a single complex entity called
object, breaking down the system into its various objects, and combining the data and
operations in objects.
• OOA increases the understanding of problem domains, promotes a smooth transition
from the analysis phase to the design phase, and provides a more natural way of
organizing specifications.

21. 4. Prototyping Analysis
• Prototyping is more suitable where requirements are not known in advance, rapid
delivery of the product is required, and the customer involvement is necessary in
software development.
• It is an iterative approach that begins with the partial development of an executable
model of the system. It is then demonstrated to the customer for the collection of
feedback.
• The development of prototype is repeated until it satisfies all the needs and until it is
considered the final system.
• Prototype can be developed either using automated tools and 4GL.

22. Use Case Diagram

23. It describes a functional requirement of the system as a whole from an external
perspective.
A use case diagram can summarize the details of your system's users (also known as
actors) and their interactions with the system.
Use cases specify the expected behavior (what), and not the exact method of making
it happen (how).
A key concept of use case modeling is that it helps us design a system from the end
user's perspective.
It is an effective technique for communicating system behavior in the user's terms by
specifying all externally visible system behavior.
What is a Use Case?

25. Actors: The users that interact with a system. An actor can be a person, an organization, or
an outside system that interacts with your application or system. They must be external
objects that produce or consume data.
System: A specific sequence of actions and interactions between actors and the system. A
system may also be referred to as a scenario.
Goals: The end result of most use cases. A successful diagram should describe the
activities and variants used to reach the goal.
Components of Use case Diagram

26. Notation Description Visual Representation
Actor
•Someone interacts with use case (system function).
•Named by noun.
•Actor plays a role in the business
•Actor triggers use case(s).
•Actor has a responsibility toward the system (inputs), and
Actor has expectations from the system (outputs).

27. Use Case
System function (process - automated or manual)
Named by verb + Noun (or Noun Phrase).
i.e. Do something
Each Actor must be linked to a use case, while some use
cases may not be linked to actors.
Communication Link
The participation of an actor in a use case is shown by
connecting an actor to a use case by a solid link.
Actors may be connected to use cases by associations,
indicating that the actor and the use case communicate with
one another using messages.

28. Boundary of system
The system boundary is potentially the entire
system as defined in the requirements
document.
For large and complex systems, each module
may be the system boundary.

29. Use Case Relationship
There can be 5 relationship types in a use case diagram.
1. Association between actor and use case
2. Generalization of an actor
3. Extend between two use cases
4. Include between two use cases
5. Generalization of a use case

30. 1. Association Between Actor and Use Case
This one is straightforward and present in every use case diagram. Few things to note.
An actor must be associated with at least one use case.
An actor can be associated with multiple use cases.
Multiple actors can be associated with a single use case.
use case diagram relationships for actor and use case

32. 3. Extend Relationship Between Two Use Cases
Many people confuse the extend relationship in use cases. As the name implies it
extends the base use case and adds more functionality to the system.
The extending use case is dependent on the extended (base) use case. In the below
diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit
Funds” use case.
The extending use case is usually optional and can be triggered conditionally. In the
diagram, you can see that the extending use case is triggered only for deposits over
10,000 or when the age is over 55.
The extended (base) use case must be meaningful on its own. This means it should be
independent and must not rely on the behavior of the extending use case.

34. 4. Include Relationship Between Two Use Cases
Include relationship show that the behavior of the included use case is part of the
including (base) use case. The main reason for this is to reuse common actions across
multiple use cases.
Few things to consider when using
the <<include>> relationship.
1. The base use case is incomplete
without the included use case.
2. The included use case is
mandatory and not optional.

35. 5. Generalization of a Use Case
This is similar to the generalization of an actor. The behavior of the ancestor is inherited
by the descendant.

36. An organization wants to develop the system based on following Requirements:
1. Students have to register first through fill up the registration form.
2. Faculty can prepare the grade sheet of concern subjects.
3. Student and faculty can see the result of each student.
4. Faculty can generate the report about registered students.
5. System can verify the students Registration Details First.
6. Student may have to fill up the hostel details during registration process.

37. Use Case Template

40. Types of Requirements

41. Functional Requirements
functional requirements can be defined as ‘a function that a system or component
must be able to perform.’
These requirements describe the interaction of software with its environment and
specify the inputs, outputs, external interfaces, and the functions that should be
included in the software.
Also, the services provided by functional requirements specify the procedure by which
the software should react to particular inputs or behave in particular situations.
Examples
The user shall be able to search either all of the initial set of databases or select a
subset from it
The system shall provide appropriate viewers for the user to read documents
in the document store.

42. Non-Functional Requirements
The non-functional requirements (also known as quality requirements) are related to
system attributes such as reliability and response time.
Nonfunctional software requirements define how the system must operate or perform.
They cover:
performance
usability
scalability
security
portability

43. They are further classified as
Product requirements
Requirements which specify that the delivered product must behave in a particular
way, e.g. execution speed, reliability.
Organizational requirements
Requirements which are a consequence of organizational policies and procedures,
e.g. process standards used, implementation requirements etc.
External requirements
Requirements which arise from factors which are external to the system and its
development process, e.g. interoperability requirements, legislative requirements.

46. Domain Requirements
Requirements which are derived from the application domain of the system instead from
the needs of the users are known as domain requirements.
These requirements may be new functional requirements or specify a method to perform
some particular computations.
Example: Security mechanism for the files and documents used in the system are also
domain requirements.

47. SRS – Requirement Documentation
A software requirements specification (SRS) is a detailed description of a software system
to be developed with its functional and non-functional requirements.
The SRS is developed based the agreement between customer and contractors.
This document is generated as output of requirement analysis. The requirement
analysis involves obtaining a clear and thorough understanding of the product to be
developed.
Thus, SRS should be consistent, correct, unambiguous & complete, document. The
developer of the system can prepare SRS after detailed communication with the
customer.

48. An SRS clearly defines the following:
1. External Interfaces of the system: They identify the information which is to flow
„from and to’ to the system.
2. Functional and non-functional requirements of the system. They stand for the finding
of run time requirements.
3. Design constraints:

49. Software requirement specification is a kind of document which is created by a software
analyst after the requirements collected from the various sources - the requirement
received by the customer written in ordinary language.
It is the job of the analyst to write the requirement in technical language so that they can
be understood and beneficial by the development team.

50. Need for SRS…
 Helps user understand his needs.
 users do not always know their needs
 must analyze and understand the potential
 The requirement process helps clarify needs
 SRS provides a reference for validation of the final product
 Clear understanding about what is expected.
 Validation - “ SW satisfies the SRS “
50

51. Need for SRS…
• High quality SRS essential for high Quality SW
• Requirement errors get manifested in final sw
• To satisfy the quality objective, must begin with high quality SRS
• Requirements defects cause later problems
• 25% of all defects in one study; 54% of all defects found after user testing
• defects often found in previously approved SRS.
51

52. Characteristics of an SRS
• Correct
• Complete
• Unambiguous
• Consistent
• Verifiable
• Traceable
• Modifiable
• Ranked for importance and/or stability
52

53. Characteristics…
• Correctness
• Each requirement accurately represents some desired feature in the final system
• Completeness
• All desired features/characteristics specified
• Hardest to satisfy
• Completeness and correctness strongly related
• Unambiguous
• Each req has exactly one meaning
• Without this errors will creep in
• Important as natural languages often used
53

54. Characteristics…
• Verifiability
• There must exist a cost effective way of checking if sw satisfies requirements
• Consistent
• two requirements don’t contradict each other
• Traceable
• The origin of the req, and how the req relates to software elements can be
determined
• Ranked for importance/stability
• Needed for prioritizing in construction
• To reduce risks due to changing requirements
54

55. Components of an SRS
• What should an SRS contain ?
• Clarifying this will help ensure completeness
• An SRS must specify requirements on
• Functionality
• Performance
• Design constraints
• External interfaces
55

56. Functional Requirements
• Heart of the SRS document; this forms the bulk of the specs
• Specifies all the functionality that the system should support
• Outputs for the given inputs and the relationship between them
• All operations the system is to do
• Must specify behavior for invalid inputs too
56

57. Performance Requirements
• All the performance constraints on the software system
• Generally on response time , throughput etc => dynamic
• Capacity requirements => static
• Must be in measurable terms (verifiability)
• Eg resp time should be xx 90% of the time
57

58. Design Constraints
• Factors in the client environment that restrict the choices
• Some such restrictions
• Standard compliance and compatibility with other systems
• Hardware Limitations
• Reliability, fault tolerance, backup req.
• Security
58

59. External Interface
• All interactions of the software with people, hardware, and sw
• User interface most important
• General requirements of “friendliness” should be avoided
• These should also be verifiable
Requirements 59

60. SRS Outline
1. Introduction
• 1.1 Purpose
• 1.2 Scope
• 1.3 Definitions, acronyms, and abbreviations 1.4 References
• 1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies

61. 3. Specific requirements
• 3.1 External Interfaces
• 3.2 Functional requirements
• 3.3 Performance requirements
• 3.4 Logical Database requirements
• 3.5 Design Constraints
• 3.6 Software system attributes
• 3.7 Organising the specific requirements
• 3.8 Additional Comments
4. Supporting information
• 4.1 Table of contents and index
• 4.2 Appendixes