Software Engineering Principles and Practices

Department of Collegiate and Technical Education
Week -6
Requirement Engineering & Modeling
Software Engineering Principles
and Practices
Computer Science and Engineering
Session 02
Computer Science & Engineering – 20CS44P

REQUIREMENT ENGINEERING PROCESS
Requirements Engineering Processes may include four high-
level activities.
• Feasibility study : These focus on assessing if the system is
useful to the business
• Elicitation and Analysis : discovering requirements
• Specification : converting these requirements into some
standard form and
• Validation : checking that the requirements actually define
the system that the customer wants

Feasibility study
A feasibility study is a short, focused study that should take
place early in the RE process. It should answer three key
questions:
• Does the system contribute to the overall objectives of the
organization?
• Can the system be implemented within schedule and budget
using current technology? And
• Can the system be integrated with other systems that are
used?

Requirements elicitation and analysis

Requirements discovery
• This is the process of interacting with stakeholders of the
system to discover their requirements
• Domain requirements from stakeholders and documentation
are also discovered during this activity

Requirements classification and organization
• This activity takes the unstructured collection of
requirements, groups related requirements, and organizes
them into coherent clusters
• The most common way of grouping requirements is to use a
model of the system architecture to identify sub-systems and
to associate requirements with each sub-system

Requirements prioritization and negotiation
• Inevitably, when multiple stakeholders are involved,
requirements will conflict.
• This activity is concerned with prioritizing requirements and
finding and resolving requirements conflicts through
negotiation.
• Usually, stakeholders have to meet to resolve differences
and agree on compromise requirements.

Requirements specification
• The requirements are documented and input into the next
round of the spiral.
• Formal or informal requirements documents may be
produced.

Requirements specification
• 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.

The models used at this stage include ER diagrams, data flow
diagrams (DFDs), function decomposition diagrams (FDDs),
data dictionaries, etc.
• Data flow diagrams (DFDs) : They are used widely for
modelling the requirements. DFD shows the flow of data
through a system
• Data Dictionaries: Data Dictionaries are simply repositories
to store information about all data items defined in DFDs

• Entity-Relationship Diagrams: Another tool for
requirement specification is the entity-relationship diagram,
often called an "E-R diagram."
• It is a detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.

Requirements validation
• Requirements validation is the process of checking that
requirements actually define the system that the customer
really wants.
• It overlaps with analysis as it is concerned with finding
problems with the requirements.
• Requirements validation is important because errors in a
requirements document can lead to extensive rework costs
when these problems are discovered during development or
after the system is in service.

During the requirements validation process, different types
of checks should be carried out on the requirements in the
requirements document. These checks include:
• Validity checks A user may think that a system is needed to
perform certain functions.
• Consistency checks Requirements in the document should
not conflict.

• Completeness checks The requirements document should
include requirements that define all functions and the
constraints intended by the system user.
• Realism checks Using knowledge of existing technology,
the requirements should be checked to ensure that they can
actually be implemented.
• Verifiability To reduce the potential for dispute between
customer and contractor, system requirements should always
be written so that they are verifiable.

Typical Requirements Engineering Problems
• Understanding large and complex system requirements is
difficult
• Undefined system boundaries
• Customers/Stakeholders are not clear about their needs
• Conflicting requirements are there
• Changing requirements is another issue
• Partitioning the system suitably to reduce complexity

• Validating and Tracing requirements
• Identifying critical requirements
• Resolving the “to be determined” part of the requirements
• Proper documentation, proper meeting time, and budget
constraints

Thank you
Chairperson: Smt. Usha D 136-Government Polytechnic, Bagepalli
Moderator :
Smt. Sunandadevi V K
109-136-Government Polytechnic,
Kalaburagi
Subject Rewiever
Smt. Suvarna Mahadev V M
136-Government Polytechnic, Bagepalli
Content Developers
1. LOHITH S Y
173-gpt, Harapanahalli
2. Raghavendra M 131 School of Mines KGF
3.Poornima Kebbepura R C 112, Gpt, Tumkur
4. O K MANJUNATHA 156 GPT MULBAGAL
5. JYOTHI B.K 177 GPT SIDDAPUR.
6. PALLAVI H S 169 GPT KGF
7. A V RADHIKA 149, GPT ,CHITRADURGA

Software Engineering Principles and Practices

More Related Content

Similar to Software Engineering Principles and Practices

Recently uploaded

Software Engineering Principles and Practices