Unit 2: Software Requirement, Modelling and Design

1. Requirements Engineering:
 The Requirement engineering is the process of gathering the software
requirements from client, analysing and document them. The aim of
requirement engineering is to develop and maintain sophisticated and
descriptive System Requirements Specification (SRS)’ documents.
 Requirements engineering is the area of systems engineering that deals with
the process of developing and verifying the system requirements
 Steps involving in Requirements Engineering

1. Feasibility Study: Feasibility study is first step of the requirements

engineering process. The worthiness of the proposed software
system should be determined before spending on building the
system.
2. Requirements Elicitation: Gathering information about requirements
by interacting with customers, examining the market, and identifying
potential sources of requirements.
3. Requirements Analysis: Understanding and refining the gathered
requirements, resolving conflicts, and achieving consensus among
stakeholders through techniques like modeling or prototyping.
4. Requirements Specification: Documenting the analyzed requirements
in a clear, structured, and unambiguous format that developers can
understand and act upon.
5. Requirements Validation: Checking if the documented requirements
are correct and ensure that the "right" system is being built, ensuring
alignment with stakeholder needs.
6. Requirements Management: The ongoing process of tracking,
controlling, and adapting requirements as the project evolves,
ensuring changes are managed effectively.

2. Requirement Engineering Task:

 RE(Requirement Engineering) provides an appropriate mechanism of
understanding what the customer wants, assessing feasibility, analyzing need,
negotiating a reasonable solution, managing the requirement, validating the
specification and specifying the solution as they are transformed into an
operational system.
 The process to determine the requirement specification of the software is called
the Requirement Engineering (RE) process.
 The requirements engineering process is achieved through the execution of seven
distinct functions. These functions are Inception, Elicitation, Elaboration,
Negotiation, Specification, Validation, and Management.
 User

Inception

Negotiation

Elicitation

Final functional requirements

Elaboration

Requirement
Specifications
Validation

Requirement
Management

Fig: Requirement engineering task

1. Inception

This is the first phase of the requirements analysis process. This phase gives an outline of
how to get started on a project .A basic understanding of the problem is gained and the
nature of the solution is addressed. Overall in the inception phase. Understanding of the
problem.

 The people who want a solution.

 Nature of the solution.
 Communication and collaboration between the customer and developer.

2. Elicitation

This is the second phase of the requirements analysis process. This phase focuses on
gathering the requirements from the stakeholders. One should be careful in this phase, as
the requirements are what establishes the key purpose of a project.

 Problem of Scope
 Problem of Understanding:
 Problem of Volatility
3. Elaboration

This is the third phase of the requirements analysis process. This phase is the result of the
inception and elicitation phase. In the elaboration process, it takes the requirements that
have been stated and gathered in the first two phases and refines them.

4. Negotiation

This is the fourth phase of the requirements analysis process. This phase emphasizes
discussion and exchanging conversation on what is needed and what is to be eliminated. In
the negotiation phase, negotiation is between the developer and the customer and they
dwell on how to go about the project with limited business resources.

5. Specification

This is the fifth phase of the requirements analysis process. This phase specifies the
following:

 Written document.
 A set of models.
 A collection of use cases.
 A prototype.

6. Validation

This is the sixth phase of the requirements analysis process. This phase focuses on checking
for errors and debugging. In the validation phase, the developer scans the specification
document and checks.

7. Requirement Management

This is the last phase of the requirements analysis process. Requirements management is a
set of activities where the entire team takes part in identifying, controlling, tracking, and
establishing the requirements for the successful and smooth implementation of the project.

Types of Requirements:
 Software system requirements are often classified as functional requirement and
non-functional requirements.
 Functional requirements are statements of services the system should provide, how
the system should react to particular input and how the system should behave in
particular situations.
 Non-functional requirements are constraints on the services or functions offered by
standards. Shows the various types of non-functional requirements are :
3. Developing Use-Cases:
 Use cases identified the actors involved in an interaction and name the type of
interaction. This is then supplemented by additional information.
 Use cases are documented using a high-level use case diagram. The set of use cases
represents all of the possible interactions that will be described in the system
requirements.
 Another way to look at it is a use case describes a way in which a real-world actor
interacts with the system.
 In a system use case you include high-level implementation decisions. System use
cases can be written in both an informal manner and a formal manner.
 Determine all entities that interact with the system. Actors can be human users,
other systems, or external devices. Differentiate between primary actors
 Define the distinct functionalities or tasks the system must perform. Each use case
represents a specific goal an actor wants to achieve.
 Fig: Use Cases
4. SRS (Software Requirements Specification):
 Software Requirement Specification (SRS) Format as the name suggests, is a
complete specification and description of requirements of the software that need to
be fulfilled for the successful development of the software system.
 These requirements can be functional as well as non-functional depending upon the
type of requirement. The interaction between different customers and contractors is
done because it is necessary to fully understand the needs of customers.
 Features of SRS:
1. It forms the basis for software development.
2. SRS provides a reference for validation of the final software product.
3. It is a medium or media thought the client and used needs are accurately
specified determined.
4. SRS helps to clients to understand their own needs and requirements.
 Purpose served by SRS:
1. Feedback
2. Decompose problem into components
3. Validation
4. Input to Design
5. Basis for Agreement Between the User and the Organization
6. Reduce the Development Effort

Concept of SRS:
 Requirements documents are essential when an outside contractor is developing the
software system. The Software Requirements Specification is a technical specification
of the requirements for the software product.
 The SRS records the outcome of the software requirements definition activity. SRS
also known as requirements documents.
 However, the simplified outline presented in fig may be used as a framework for a
specification.
1. Introduction
2. Information description
3. Functional description
4. Behavioral description
5. Validation and criteria
6. Bibliography
7. Appendix
 Needs/Importance of SRS:
1. There are three major parties interested in a system i.e. the client, the users,
the developers. Somehow the requirements for the system that will satisfy
the needs of the clients and the concerns of the users have to be
communicated to the developer.
2. Another important purpose of developing and SRS is helping the clients
understand their own needs or requirements.
3. SRS is important because it establish the basis of agreement between client
and the supplier on what the software product will do
4. An SRS provides a reference of validation of the final product

 Characteristics of SRS

1. Correct: SRS is correct when all user requirements are stated in the requirements
document. The stated requirement should be according to the desired system
2. Unambiguous: SRS is an ambiguous when every stated requirement has only one
interpretation this implies that each requirement is uniquely interpreted
3. Complete: SRS is complete when the requirement clearly defines what the
software is required to do
4. Rank for importance/ Stability: All requirements are equally important; hence
each requirement is identified to make differences among requirements
5. Modifiable: The requirements of the user can change hence required documents
should be created in such manner that those changes can be modified easily
6. Trackable: SRS is trackable when the source of each requirement is clear and
facilitates the reference of each requirement in future.
7. Verify: SRS is verified when the specified requirement can be verified with a cost-
effective process to check whether the final software need those requirements
8. Consistent: SRS is consistent when the subsets of individual requirements
defined not to conflict with each other.
 SRS Format:
 SRS is the standard statement of what the system developers should
implement. SRS include user’s requirement for a system and detailed
specification of the system requirements.
 SRS format is a complete specification and description of requirements of the
software that need to be fulfilled for the successful development of the
software system.
 SRS is a format document. It uses natural language, graphical representations,
mathematical models, usage scenarios, prototype model or any combination
of these to describe the software to be developed.
 The SRS document should be well-structured. A well-structured document is
easy to understand and modify.

 Translating Requirement Model into Design Model

 Software design is applied regardless of the software process model that is
used. Beginning once software requirements have been analyzed and
specified, software design is the first of three technical activities-design, code
generation, and test.
 These activities are required to build and verify the software. Each activity
transforms information in a manner that ultimately in validated computer
software.
a. The data/class design transforms analysis classes into design classes
along with the data structures required to implement the software.
 b. The architectural design defines the relationship between major
structural elements of the software; architectural styles and design
patterns help achieve the requirements defined for the system.
c. The interface design describe how the software communicates with
system that interoperates with it and with humans that use it.
d. The component-level design transforms structural elements of the
software architecture into procedural description of software
components.

 Design Modelling:
 A design model in software engineering is a detailed, architectural blueprint
that outlines a system's data structures, user interfaces, and components,
allowing for quality assessment and modification before implementation.
 Design modeling in software engineering represents the features of the
software that helps engineer to develop it effectively, the architecture, the
user interface, and the component level detail.
 Software design phases are design, code, and test.
  Characteristics of Good Design:
I. The design must implement all of the explicit requirements contained in the
requirements model and it must accommodate all of the implicit
requirements.
II. The design must be a readable, understandable guide for those who generate
code and for those who test and subsequently support the software.
III. The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation
perspective.
Design Quality Guidelines:
I. A design should be modular i.e. the software should be logically partitioned
into elements or subsystems.
II. A design should contain distinct representations of data, architecture,
interfaces, and components.
III. A design should lead to that structure that are exhibit independent functional
Characteristics.
Design Concepts:
I. A set of fundamental software design concepts has evolved over the history of
software engineering. Each provides the software designer with a foundation
from which more sophisticated design methods can be applied.
II. How function or data is structure detail separated from a conceptual
representation of the software?
III. What uniform criteria define the technical quality of a software design?
Abstraction:
 Abstraction is the act of representing essential features without
including the background details or explanations. The abstraction is
used to reduce complexity and allow efficient design and
implementation of complex software systems.
 Many levels of abstraction can be posed. At the highest level of
abstraction, a solution is stated in broad terms using the language of
the problem environment. At lower levels of abstraction, a more
detailed description of the solution is provided.
 As different levels of abstraction are developed, you work to create
both procedural and data abstractions.

Information Hiding:
 The principle of information hiding suggests that modules be “characterized
by design decisions that hides from all others.”
 In other words, modules should be specified and designed so that information
contained within a module is inaccessible to other modules that have no need
for such information.

Modularity:
 Modularity is the most common manifestation of separation of concerns.
Software is divided into separately named and addressable components,
sometimes called module.
 Modularity is the single attribute of software that allows a program to be
intellectually manageable

Structure:
 Structure is a fundamental characteristics of computer software. The use of
structuring permits decomposition of a large system into smaller, more
manageable units with well-defined relationship to the other units in system.
 A set of architectural patterns enables a software engineer to solve common
design problems
 Given the specification of these properties the architectural design can be
represented using one or more of a number of different models:
I. Structural Model
II. Framework Model
III. Dynamic Model
IV. Process Model
Concurrency:
 In software design, concurrency is implemented by splitting the software into
multiple independent units of execution, like modules and executing them in
parallel. In other words, concurrency provides capability to the software to
execute more than one part of code in parallel to each other.
 It is necessary for the programmers and designers to recognize those
modules, which can be made parallel execution.

Verification:
 Verification is a fundamental concept in software design. Design is the bridge
between customer requirements and an implementation of software that
satisfies design is verifiable if it can be demonstrated that those requirements.
 A design is verifiable if it can be demonstrated that the design will result in an
implementation that satisfies the customer’s requirements

Aesthetics:
 Aesthetic design in software engineering focuses on making software visually
pleasing and engaging, balancing its functionality with attractive, user-friendly
layouts and experiences.
 Color, balance, symmetry, contrast and fonts are the important key elements
in aesthetic design.

Design Notations:
 The concept of a notation (graphical, or tabular mechanism used for
displaying or formulating) is the keystone to the utilization of a methodology.
 Design notations are used when planning and should be able to communicate
the purpose of a program without the need for formal code.
 Commonly used design notations are:
1. flow charts
2. structure diagrams

Data Flow Diagrams (DFD)

 Data Flow Diagram (DFD) is a graphical representation of the flow of data
through an information system. It enables us to represent in the information
system from the viewpoint of data.
 A data flow diagram also known as bubble chart or work flow diagram.
 Data flow diagrams are important because they make it easier to understand
the flow of information through complex systems or processes.
 DFD accomplishes the following objectives:
 1. A DFD represents system data in a hierarchical manner and with
required levels of detail.
2. A DFD depict processes according to defined user requirements and
software scope.

Types of DFDs:

 There are two types of DFDs, both of which support a top-down approach to
systems analysis as given below:
1. Logical DFDs: Logical data flow diagram mainly focuses on the system
process. In the Logical Data Flow Diagram (DFD), we focus on the
high-level processes and data flow without delving into the specific
implementation details.
2. Physical DFDs: Physical data flow diagram shows how the data flow is
actually implemented in the system. In the Physical Data Flow
Diagram (DFD), we include additional details such as data storage,
data transmission, and specific technology or system components.
 To understand various levels of DFD, let us consider an example of Banking
System. In a banking system, the customer of bank (account holder) deposits
money and gets the payment receipt. The context diagram is shown below
Structured Flowchart:
Que: State requirement for given modules of online shopping system:
(i) Order module (ii) Accountant module (iii) Categories module
Ans: Here are the detailed requirements for each module:
1-Order Module
This module handles the core process of customer purchases.
Order Creation: Users must be able to add products to a shopping cart and proceed
to a checkout process to place an order.
Payment Integration: The system needs to integrate with payment gateways to
process transactions securely.
Shipping: Support for defining shipping methods, calculating shipping costs, and
generating shipping labels is required.
Status Updates: The module should allow for tracking and updating the order status
(e.g., pending, processing, shipped, delivered) and notifying the customer.
Order History: Customers should be able to view their past orders.

Order Management: Administrators need tools to view, manage, and process orders.
2-Categories Module
This module organizes and presents products to customers.
Product Organization:
The system must allow for the creation, editing, and deletion of product categories
and subcategories.

Product Assignment:
Products need to be assignable to one or more categories.
Navigation:
Users should be able to browse and filter products by category to find what they are
looking for.
Display:
Categories should be clearly displayed on the website, often in menus or sidebars.

3-Accountant Module
This module handles the financial aspects of the online store.
Sales Tracking:
Record and track all sales transactions, including revenue, discounts, and taxes.
Inventory Management & Valuation:

Manage stock levels, track costs, and determine the value of inventory for accounting
purposes.
Financial Reporting:
Generate reports such as profit and loss statements, balance sheets, and cash flow
statements.
Tax Calculation:
Accurately calculate and report sales tax based on location and product type.
Payment Reconciliation:

Track payments received, reconcile them with sales data, and handle refunds.
User Permissions:
Define roles and permissions for financial users to control access to sensitive financial
data.

Que: identify and enlist requirement for given modules of employee management
software i) employee details ii) employee salary iii) employee performance.
Ans- Here are the requirements for each module of the Employee Management
System:

Module 1: Employee Details

1. Employee Profile: Store employee personal details, such as name, date of birth,
contact information, and emergency contact details.
2. Employee ID: Assign a unique employee ID to each employee.
3. Job Details: Store employee job details, such as job title, department, and
manager.
4. Employment History: Store employee employment history, including previous
employers and job titles.
5. Education and Qualifications: Store employee education and qualification details.

6. Skills and Certifications: Store employee skills and certification details.

7. Search and Filter: Allow administrators to search and filter employees by various
criteria, such as department, job title, or location.

Module 2: Employee Salary

1. Salary Structure: Define salary structures for different job titles and departments.
2. Salary Calculation: Calculate employee salaries based on their salary structure,
attendance, and performance.
3. Payroll Processing: Process employee payroll, including generating pay slips and
managing deductions.
4. Tax Calculation: Calculate employee taxes and generate tax reports.
5. Benefits Management: Manage employee benefits, such as health insurance,
retirement plans, and other perks.
6. Salary History: Store employee salary history, including previous salary changes
and increments.
7. Reporting: Generate reports on employee salaries, payroll, and benefits.

Module 3: Employee Performance

1. Performance Evaluation: Conduct regular performance evaluations, including

setting goals and objectives.
2. Performance Metrics: Define performance metrics, such as key performance
indicators (KPIs).
3. Performance Tracking: Track employee performance against set goals and metrics.

4. Feedback and Coaching: Provide employees with feedback and coaching to

improve their performance.

5. Performance Improvement Plans: Develop performance improvement plans for

underperforming employees.
6. Performance Reports: Generate reports on employee performance, including
performance evaluations and ratings.
7. Succession Planning: Identify and develop future leaders through succession
planning.

Que: Draw data flow diagram level 0 and level 1 for book publishing house
Ans:
Que: Draw data flow diagram level 0 and level 1 for railway reservation management
Ans:
Que: Draw data flow diagram level 0 and level 1 for library management system.

Ans: Here the data flow diagram level 0 and level 1 for library management system

DFD Level 0-
DFD Level 1-

DFD Level 2-