IT 14 : Software

Engineering and Project

Management

Prepared By : Prof. Karishma Kamble

 Point to be covered
• Overview of Software Engineering
• SDLC models
• Requirement Engineering
• Types of Requirements: -Functional and Non-functional
• Four Phases of Requirement Engineering
• Software requirement Specification (SRS)
• Structure and contents of SRS
• IEEE SRS Format
What is Software Engineering
Software: is more than just a program code.

• A program is an executable code, which serves some computational purpose.

• Software is considered to be collection of executable programming code, associated libraries and documentations.

• Software, when made for a specific requirement is called software product.

Engineering: on the other hand, is all about developing products, using well-defined, scientific principles and methods.

Software Engineering is the process of designing, developing, testing, and maintaining software. It is a systematic and

disciplined approach to software development that aims to create high-quality, reliable, and maintainable software .
Overview of Software Engineering

• According to Boehm : “Software Engineering the application of science and mathematics by which the capabilities of
computer equipment are made useful to man through computer programs, procedures and associated documentation”.
• Software engineering includes a variety of techniques, tools, and methodologies, including requirements analysis, design, testing, and maintenance.

• It is a rapidly evolving field, and new tools and technologies are constantly being developed to improve the software development process.

• By following the principles of software engineering and using the appropriate tools and methodologies, software developers can create high-quality,
reliable, and maintainable software that meets the needs of its users.

• Software Engineering is mainly used for large projects based on software systems rather than single programs or applications.

• The main goal of Software Engineering is to develop software applications for improving quality, budget, and time efficiency.

• Software Engineering ensures that the software that has to be built should be consistent, correct, also on budget, on time, and within the required
requirements.
 Benefits of Software Engineering
• Improved Quality: By following established software engineering principles and techniques, the software can be developed
with fewer bugs and higher reliability.

• Increased Productivity: Using modern tools and methodologies can streamline the development process, allowing developers
to be more productive and complete projects faster.

• Better Maintainability: Software that is designed and developed using sound software engineering practices is easier to
maintain and update over time.

• Reduced Costs: By identifying and addressing potential problems early in the development process, software engineering can
help to reduce the cost of fixing bugs and adding new features later on.
Benefits of Software Engineering
• Increased Customer Satisfaction: By involving customers in the development process and developing software that meets
their needs, software engineering can help to increase customer satisfaction.

• Better Team Collaboration: By using Agile methodologies and continuous integration, software engineering allows for
better collaboration among development teams.

• Better Scalability: By designing software with scalability in mind, software engineering can help to ensure that software
can handle an increasing number of users and transactions.

• Better Security: By following the Software Development Life Cycle (SDLC) and performing security testing, software
engineering can help to prevent security breaches and protect sensitive data.
 Software development life cycle (SDLC)
• Software development life cycle (SDLC) is a structured process that is used to design, develop,
and test good-quality software.

• SDLC, or software development life cycle, is a methodology that defines the entire procedure of
software development step-by-step.
Stage-1: Planning and Requirement Analysis

• Planning is a crucial step in everything, just as in software development. In this same stage,
requirement analysis is also performed by the developers of the organization.

• This is attained from customer inputs, and sales department/market surveys.

Stage-2: Defining Requirements

• In this stage, all the requirements for the target software are specified. These requirements get
approval from customers, market analysts, and stakeholders.

• This is fulfilled by utilizing SRS (Software Requirement Specification). This is a sort of document that
specifies all those things that need to be defined and created during the entire project cycle.
Stage-3: Designing Architecture

• SRS is a reference for software designers to come up with the best architecture for the software.
Hence, with the requirements defined in SRS, multiple designs for the product architecture are
present in the Design Document Specification (DDS).

• This DDS is assessed by market analysts and stakeholders. After evaluating all the possible
factors, the most practical and logical design is chosen for development.
Stage-4: Developing Product

• At this stage, the fundamental development of the product starts. For this, developers use a
specific programming code as per the design in the DDS.

• Hence, it is important for the coders to follow the protocols set by the association.

• Conventional programming tools like compilers, interpreters, debuggers, etc. are also put into use
at this stage.

• Some popular languages like C/C++, Python, Java, etc. are put into use as per the software
regulations.
Stage-5: Product Testing and Integration

• After the development of the product, testing of the software is necessary to ensure its smooth
execution. Although, minimal testing is conducted at every stage of SDLC.

• Therefore, at this stage, all the probable flaws are tracked, fixed, and retested.

• This ensures that the product confronts the quality requirements of SRS.
Stage-6: Deployment and Maintenance of Products

• Once the product is tested and ready to be deployed it is released formally in the appropriate
market.

• Sometimes product deployment happens in stages as per the business strategy of that organization.

• The product may first be released in a limited segment and tested in the real business environment
(UAT- User acceptance testing).
 SDLC Model
• Software Development life cycle (SDLC) is a spiritual model used in project management that
defines the stages include in an information system development project, from an initial feasibility
study to the maintenance of the completed application.

• There are different software development life cycle models specify and design, which are followed
during the software development phase.

• These models are also called "Software Development Process Models." Each process model
follows a series of phase unique to its type to ensure success in the step of software development.
SDLC Model
 1. WaterFall Model
• Waterfall approach was first SDLC Model to be used widely in
Software Engineering to ensure success of the project.

• In "The Waterfall" approach, the whole process of software

development is divided into separate phases.

• In this Waterfall model, typically, the outcome of one phase acts as

the input for the next phase sequentially.

• The waterfall is a universally accepted SDLC model. In this

method, the whole process of software development is divided
into various phases.
 WaterFall Model Phases
1. Requirements analysis and specification phase:

• The aim of this phase is to understand the exact requirements of the customer and to document them
properly.

• Both the customer and the software developer work together so as to document all the functions,
performance, and interfacing requirement of the software.

• It describes the "what" of the system to be produced and not "how."In this phase, a large
document called Software Requirement Specification (SRS) document is created which
contained a detailed description of what the system will do in the common language.
 WaterFall Model Phases
2. Design Phase:
• This phase aims to transform the requirements gathered in the SRS into a suitable form which permits further coding in a programming language.

• It defines the overall software architecture together with high level and detailed design. All this work is documented as a Software Design Document (SDD).

3. Implementation and unit testing:

• During this phase, design is implemented. If the SDD is complete, the implementation or coding phase proceeds smoothly, because all the information needed by

software developers is contained in the SDD.

• During testing, the code is thoroughly examined and modified. Small modules are tested in isolation initially. After that these modules are tested by writing some

overhead code to check the interaction between these modules and the flow of intermediate output.
 WaterFall Model
4. Integration and System Testing:
• This phase is highly crucial as the quality of the end product is determined by the effectiveness of the
testing carried out.
• The better output will lead to satisfied customers, lower maintenance costs, and accurate results. Unit
testing determines the efficiency of individual modules.
• However, in this phase, the modules are tested for their interactions with each other and with the system.

5. Operation and maintenance phase:

• Maintenance is the task performed by every user once the software has been delivered to the customer,
installed, and operational.
 When to use SDLC Waterfall Model
• Some Circumstances where the use of the Waterfall model is most suited are:

• When the requirements are constant and not changed regularly.

• A project is short

• The situation is calm

• Where the tools and technology used is consistent and is not changing

• When resources are well prepared and are available to use.

 Advantages of Waterfall model
• This model is simple to implement also the number of resources that are required for it is minimal.

• The requirements are simple and explicitly declared; they remain unchanged during the entire project
development.

• The start and end points for each phase is fixed, which makes it easy to cover progress.

• The release date for the complete product, as well as its final cost, can be determined before development.

• It gives easy to control and clarity for the customer due to a strict reporting system.
 Disadvantages of Waterfall model
• In this model, the risk factor is higher, so this model is not suitable for more significant and complex
projects.

• This model cannot accept the changes in requirements during development.

• It becomes tough to go back to the phase. For example, if the application has now shifted to the coding
phase, and there is a change in requirement, It becomes tough to go back and change it.

• Since the testing done at a later stage, it does not allow identifying the challenges and risks in the earlier
phase, so the risk reduction strategy is difficult to prepare.
 2. RAD Model
• RAD or Rapid Application Development process is an adoption of the waterfall model; it targets
developing software in a short period.

• The RAD model is based on the concept that a better system can be developed in lesser time by using
focus groups to gather system requirements.

• The RAD model or Rapid Application Development model is a type of software development
methodology that emphasizes quick and iterative release cycles, primarily focusing on delivering
working software in shorter timelines.
RAD Model
 RAD Model Phases
[Link] Modelling:

• The information flow among business functions is defined by answering questions like what data drives
the business process, what data is generated, who generates it, where does the information go, who
process it and so on.

[Link] Modelling:

• The data collected from business modeling is refined into a set of data objects (entities) that are needed
to support the business.

• The attributes (character of each entity) are identified, and the relation between these data objects
(entities) is defined.
 RAD Model Phases
3. Process Modelling:

• The information object defined in the data modeling phase are transformed to achieve the data flow
necessary to implement a business function.

• Processing descriptions are created for adding, modifying, deleting, or retrieving a data object.
4. Application Generation:

• Automated tools are used to facilitate construction of the software; even they use the 4th GL techniques.
5. Testing & Turnover:

• Many of the programming components have already been tested since RAD emphasis reuse.

• This reduces the overall testing time. But the new part must be tested, and all interfaces must be fully
exercised.
 When to use RAD Model?
• When the system should need to create the project that modularizes in a short span time (2-3 months).

• When the requirements are well-known.

• When the technical risk is limited.

• When there's a necessity to make a system, which modularized in 2-3 months of period.

• It should be used only if the budget allows the use of automatic code generating tools.
 Advantage of RAD Model
• This model is flexible for change.

• In this model, changes are adoptable.

• Each phase in RAD brings highest priority functionality to the customer.

• It reduced development time.

• It increases the reusability of features.

 Disadvantage of RAD Model
• It required highly skilled designers.

• All application is not compatible with RAD.

• For smaller projects, we cannot use the RAD model.

• On the high technical risk, it's not suitable.

• Required user involvement.

 3. Iterative Model

• In this Model, you can start with some of the software

specifications and develop the first version of the software.

• After the first version if there is a need to change the

software, then a new version of the software is created with a

new iteration.

• Every release of the Iterative Model finishes in an exact and

fixed period that is called iteration.

Iterative Model Phases
1. Requirement gathering & analysis:

• In this phase, requirements are gathered from customers and check by an analyst whether requirements
will fulfil or not.

• Analyst checks that need will achieve within budget or not. After all of this, the software team skips to
the next phase.

2. Design:
• In the design phase, team design the software by the different diagrams like Data Flow diagram, activity
diagram, class diagram, state transition diagram, etc.
Iterative Model Phases

3. Implementation:
• In the implementation, requirements are written in the coding language and transformed into computer
programmes which are called Software

4. Testing:
• After completing the coding phase, software testing starts using different test methods.

• There are many test methods, but the most common are white box, black box, and grey box test
methods.

5. Deployment:
• After completing all the phases, software is deployed to its work environment
Iterative Model Phases
6. Review:

• In this phase, after the product deployment, review phase is performed to check the behaviour and
validity of the developed product. And if there are any error found then the process starts again from the
requirement gathering.
7. Maintenance:
• In the maintenance phase, after deployment of the software in the working environment there may be
some bugs, some errors or new updates are required.

• Maintenance involves debugging and new addition options all the phases, software is deployed to its
work environment
 When to use Iterative Model?

• When requirements are defined clearly and easy to understand.

• When the software application is large.

• When there is a requirement of changes in future.

 Advantage of Iterative Model:
• Testing and debugging during smaller iteration is easy.

• A Parallel development can plan.

• It is easily acceptable to ever-changing needs of the project.

• Risks are identified and resolved during iteration.

• Limited time spent on documentation and extra time on designing.

Disadvantage of Iterative Model:

• It is not suitable for smaller projects.

• More Resources may be required.

• Design can be changed again and again because of imperfect requirements.

• Requirement changes can cause over budget.

• Project completion date not confirmed because of changing requirements.

 Disadvantage of Iterative Model:

• It is not suitable for smaller projects.

• More Resources may be required.

• Design can be changed again and again because of imperfect requirements.

• Requirement changes can cause over budget.

• Project completion date not confirmed because of changing requirements.

 4. Spiral Model
• The spiral methodology allows teams to adopt multiple SDLC
models based on the risk patterns of the given project.

• A blend of the iterative and waterfall approaches, the challenge

with the spiral model is knowing when is the right moment to
move onto the next phase.

• Business that aren’t sure about their requirements or expect

major edits during their mid to high-risk project can benefit from
the scalability of this methodology.
4. Spiral Model
Spiral Model Phases
1. Objectives determination and identify alternative solutions:

• Requirements are gathered from the customers and the objectives are identified, elaborated, and analyzed
at the start of every phase.

• Then alternative solutions possible for the phase are proposed in this quadrant.

2. Identify and resolve Risks:

• During the second quadrant, all the possible solutions are evaluated to select the best possible solution.

• Then the risks associated with that solution are identified and the risks are resolved using the best
possible strategy.

• At the end of this quadrant, the Prototype is built for the best possible solution.
 Spiral Model Phases

3. Develop the next version of the Product:

• During the third quadrant, the identified features are developed and verified through
testing. At the end of the third quadrant, the next version of the software is available.

4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate
the so-far developed version of the software. In the end, planning for the next phase is
started.
When to use Spiral Model?
• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
 Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.

Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.
 5. V Model
• V-Model also referred to as the Verification and Validation Model. In this, each phase of
SDLC must complete before the next phase starts.

• It follows a sequential design process same as the waterfall model. Testing of the device is
planned in parallel with a corresponding stage of development.

Verification:

• It involves a static analysis method (review) done without executing code.

• It is the process of evaluation of the product development process to find whether specified
requirements meet.

Validation:

• It involves dynamic analysis method (functional, non-functional), testing is done by

executing code.

• Validation is the process to classify the software after the completion of the development
process to determine whether the software meets the customer expectations and
requirements.
 There are the various phases of Verification Phase of V-model:
1. Business requirement analysis:

• This is the first step where product requirements understood from the customer's side.

• This phase contains detailed communication to understand customer's expectations and exact requirements.

2. System Design:

• In this stage system engineers analyze and interpret the business of the proposed system by studying the user
requirements document.

3. Architecture Design:

• The baseline in selecting the architecture is that it should understand all which typically consists of the list of
modules, brief functionality of each module, their interface relationships, dependencies, database tables,
architecture diagrams, technology detail, etc.

• The integration testing model is carried out in a particular phase.

There are the various phases of Verification Phase of V-model:

4. Module Design:

• In the module design phase, the system breaks down into small modules.

• The detailed design of the modules is specified, which is known as Low-Level Design

5. Coding Phase:

• After designing, the coding phase is started.

• Based on the requirements, a suitable programming language is decided.

• There are some guidelines and standards for coding.

• Before checking in the repository, the final build is optimized for better performance, and the code goes
through many code reviews to check the performance.
 There are the various phases of Validation Phase of V-model:
1. Unit Testing:

• In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase.

• These UTPs are executed to eliminate errors at code level or unit level.

• A unit is the smallest entity which can independently exist, e.g., a program module.

• Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/
units.

2. Integration Testing:

• Integration Test Plans are developed during the Architectural Design Phase.

• These tests verify that groups created and tested independently can coexist and communicate among
themselves.
 There are the various phases of Validation Phase of V-model:
3. System Testing:

• System Tests Plans are developed during System Design Phase.

• Unlike Unit and Integration Test Plans, System Tests Plans are composed by the clients business team.

• System Test ensures that expectations from an application developer are met.

4. Acceptance Testing:

• Acceptance testing is related to the business requirement analysis part. It includes testing the software
product in user atmosphere.

• Acceptance tests reveal the compatibility problems with the different systems, which is available within the
user atmosphere.

• It conjointly discovers the non-functional problems like load and performance defects within the real user
atmosphere.
When to use V-Model?

• When the requirement is well defined and not ambiguous.

• The V-shaped model should be used for small to medium-sized projects where requirements are clearly
defined and fixed.

• The V-shaped model should be chosen when sample technical resources are available with essential technical
expertise.
Advantage of V-Model:
• Easy to Understand.
• Testing Methods like planning, test designing happens well before coding.
• This saves a lot of time. Hence a higher chance of success over the waterfall model.
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily understood.

Disadvantage of V-Model:
• Very rigid and least flexible.
• Not a good for a complex project.
• Software is developed during the implementation stage, so no early prototypes of the software are produced.
• If any changes happen in the midway, then the test documents along with the required documents, has to be
updated.
 6. Incremental Model
• Incremental Model is a process of software development where
requirements divided into multiple standalone modules of the
software development cycle.

• In this model, each module goes through the requirements,

design, implementation and testing phases.

• Every subsequent release of the module adds function to the

previous release.

• The process continues until the complete system achieved.

Incremental Model Phases
1. Requirement analysis:

• In the first phase of the incremental model, the product analysis expertise identifies the requirements.

• And the system functional requirements are understood by the requirement analysis team.

• To develop the software under the incremental model, this phase performs a crucial role.

2. Design & Development:

• In this phase of the Incremental model of SDLC, the design of the system functionality and the development
method are finished with success.

• When software develops new practicality, the incremental model uses style and development phase.
 Incremental Model Phases
3. Testing:

• In the incremental model, the testing phase checks the performance of each existing function as well as
additional functionality.

• In the testing phase, the various methods are used to test the behavior of each task.

4. Implementation:

• Implementation phase enables the coding phase of the development system.

• It involves the final coding that design in the designing and development phase and tests the functionality in
the testing phase.

• After completion of this phase, the number of the product working is enhanced and upgraded up to the final
system product.
When to use Incremental Model

• When we use the Incremental Model?

• When the requirements are superior.

• A project has a lengthy development schedule.

• When Software team are not very well skilled or trained.

• When the customer demands a quick release of the product.

• You can develop prioritized requirements first.

Advantage of Incremental Model
• Errors are easy to be recognized.
• Easier to test and debug
• More flexible.
• Simple to manage risk because it handled during its iteration.
• The Client gets important functionality early.

Disadvantage of Incremental Model

• Need for good planning
• Total Cost is high.
• Well defined module interfaces are needed.
 7. Agile Model
• The meaning of Agile is swift or versatile."Agile process model"
refers to a software development approach based on iterative
development.

• Agile methods break tasks into smaller iterations, or parts do not

directly involve long term planning.

• The project scope and requirements are laid down at the

beginning of the development process.

• Plans regarding the number of iterations, the duration and the

scope of each iteration are clearly defined in advance.
Agile Model Phases
1. Requirements gathering:

• In this phase, you must define the requirements.

• You should explain business opportunities and plan the time and effort needed to build the project.

• Based on this information, you can evaluate technical and economic feasibility.

2. Design the requirements:

• When you have identified the project, work with stakeholders to define requirements.

• You can use the user flow diagram or the high-level UML diagram to show the work of new features and
show how it will apply to your existing system.
Agile Model Phases
3. Construction/ iteration:

• When the team defines the requirements, the work begins. Designers and developers start working on their
project, which aims to deploy a working product.

• The product will undergo various stages of improvement, so it includes simple, minimal functionality.
4. Testing:

• In this phase, the Quality Assurance team examines the product's performance and looks for the bug.
5. Deployment:

• In this phase, the team issues a product for the user's work environment.
6. Feedback:

• After releasing the product, the last step is feedback. In this, the team receives feedback about the product
and works through the feedback.
 When to use the Agile Model?
• When frequent changes are required.

• When a highly qualified and experienced team is available.

• When a customer is ready to have a meeting with a software team all the time.

• When project size is small.

 Advantage of Agile Method:
• Frequent Delivery

• Face-to-Face Communication with clients.

• Efficient design and fulfils the business requirement.

• Anytime changes are acceptable.

• It reduces total development time.

Disadvantages of Agile Model:

• Due to the shortage of formal documents, it creates confusion and crucial decisions taken throughout
various phases can be misinterpreted at any time by different team members.

• Due to the lack of proper documentation, once the project completes and the developers allotted to another
project, maintenance of the finished project can become a difficulty.
 8. Prototype Model
• In the prototyping methodology, the design team's focus is to
produce an early model of the new system, software, or
application.

• This prototype won’t have full functionality or be thoroughly

tested, but it will give external customers a sense of what’s to
come.

• Then, feedback can be gathered and implemented throughout the

rest of the SDLC phases.

• The prototyping approach works well for companies in emerging

industries or new technologies.
Steps of Prototype Model
• Requirement Gathering and Analyst

• Quick Decision

• Build a Prototype

• Assessment or User Evaluation

• Prototype Refinement

• Engineer Product
Advantage of Prototype Model
• Reduce the risk of incorrect user requirement

• Good where requirement are changing/uncommitted

• Regular visible process aids management

• Support early product marketing

• Reduce Maintenance cost.

• Errors can be detected much earlier as the system is made side by side.
Disadvantage of Prototype Model
• An unstable/badly implemented prototype often becomes the final product.
• Require extensive customer collaboration
• Costs customer money
• Needs committed customer
• Difficult to finish if customer withdraw
• May be too customer specific, no broad market
• Difficult to know how long the project will last.
• Easy to fall back into the code and fix without proper requirement analysis, design, customer evaluation,
and feedback.
• Prototyping tools are expensive.
• Special tools & techniques are required to build a prototype.
• It is a time-consuming process.
Requirement Engineering
• Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process.

• Requirement engineering provides the appropriate mechanism to understand what the customer desires,
analyzing the need, and assessing feasibility, negotiating a reasonable solution, specifying the solution
clearly, validating the specifications and managing the requirements as they are transformed into a working
system.

• Thus, requirement engineering is the disciplined application of proven principles, methods, tools, and
notation to describe a proposed system's intended behavior and its associated constraints.
Requirement Engineering Process
• It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
Requirement Engineering Process
1. Feasibility Study:

• The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to established
standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current technologies, which

are needed to accomplish customer requirements within the time and budget.

2. Operational Feasibility - Operational feasibility assesses the range in which the

required software performs a series of levels to solve business problems and customer
requirements.

3. Economic Feasibility - Economic feasibility decides whether the necessary software

can generate financial profits for an organization.
 2. Requirement Elicitation and Analysis:
• This is also known as the gathering of requirements. Here, requirements are identified with the

help of customers and existing systems processes, if available.

• Analysis of requirements starts with requirement elicitation. The requirements are analyzed to

identify inconsistencies, defects, omission, etc. We describe requirements in terms of

relationships and also resolve conflicts if any.

• Interviews: These are one-on-one conversations with stakeholders to gather information about

their needs and expectations.

• Surveys: These are questionnaires that are distributed to stakeholders to gather information

about their needs and expectations.

• Focus Groups: These are small groups of stakeholders who are brought together to discuss their

needs and expectations for the software system.

• Observation: This technique involves observing the stakeholders in their work environment to

gather information about their needs and expectations.

• Prototyping: This technique involves creating a working model of the software system, which

can be used to gather feedback from stakeholders and to validate requirements.

 3. Software Requirement 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.

 3. Software Requirement Specification

• The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs),

data dictionaries, etc.

1. Data Flow Diagrams:

• Data Flow Diagrams (DFDs) are used widely for modeling the requirements.

• DFD shows the flow of data through a system.

• The system may be a company, an organization, a set of procedures, a computer hardware system, a software system, or

any combination of the preceding.

• The DFD is also known as a data flow graph or bubble chart.

representation of the data for the organization and uses three main constructs i.e. data entities, relationships, and their

associated attributes.
 3. Software Requirement Specification

2. Data Dictionaries:

• Data Dictionaries are simply repositories to store information about all data items defined in DFDs.

• At the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and

developers use the same definition and terminologies.

3. Entity-Relationship Diagrams:

• Another tool for requirement specification is the entity-relationship diagram, often called an "E-R diagram."

• It is a detailed logical
 4. Software Requirement Validation:

• After requirement specifications developed, the requirements discussed in this document are validated.

• The user might demand illegal, impossible solution or experts may misinterpret the needs.

Requirements can be the check against the following conditions –

• If they can practically implement

• If they are correct and as per the functionality and specially of software

• If there are any ambiguities

• If they are full

• If they can describe

 4. Software Requirement Validation:

Requirements Validation Techniques

1. Requirements reviews/inspections: systematic manual analysis of the requirements.

2. Prototyping: Using an executable model of the system to check requirements.

3. Test-case generation: Developing tests for requirements to check testability.

4. Automated consistency analysis: checking for the consistency of structured requirements descriptions.
 5. Software Requirement Management :

• Requirement management is the process of analyzing, documenting, tracking, prioritizing, and agreeing on the
requirement and controlling the communication with relevant stakeholders.

• This stage takes care of the changing nature of requirements.

• It should be ensured that the SRS is as modifiable as possible to incorporate changes in requirements specified by the end
users at later stages too.

• Modifying the software as per requirements in a systematic and controlled manner is an extremely important part of the
requirements engineering process.
 5. Software Requirement Management :

Several key activities are involved in requirements management, including:

1. Tracking and controlling changes: This involves monitoring and controlling changes to the requirements throughout the
development process, including identifying the source of the change, assessing the impact of the change, and approving or
rejecting the change.

2. Version control: This involves keeping track of different versions of the requirements document and other related
artifacts.

3. Traceability: This involves linking the requirements to other elements of the development process, such as design, testing,
and validation.

4. Communication: This involves ensuring that the requirements are communicated effectively to all stakeholders and that
any changes or issues are addressed promptly.

5. Monitoring and reporting: This involves monitoring the progress of the development process and reporting on the status
of the requirements.
 Types of Requirements: -Functional and Non-functional
Requirements analysis is a very critical process that enables the success of a system or software project to be
assessed.

Requirements are generally split into two types:

1. Functional

2. Non-functional requirements.
 1. Functional
• These are the requirements that the end user specifically demands as basic
facilities that the system should offer.

• All these functionalities need to be necessarily incorporated into the system as

a part of the contract.

• These are represented or stated in the form of input to be given to the system,
the operation performed and the output expected.

• They are the requirements stated by the user which one can see directly in the
final product, unlike the non-functional requirements.

Example:

• What are the features that we need to design for this system?

• What are the edge cases we need to consider, if any, in our design?
 2. Non-functional
• These are the quality constraints that the system must satisfy according
to the project contract.
• The priority or extent to which these factors are implemented varies from
one project to another.
• They are also called non-behavioral requirements. They deal with issues
like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Example:
• Each request should be processed with the minimum latency?
• System should be highly valuable.
Difference between Function and Non- Functional
Functional Requirements Non Functional Requirements

A functional requirement defines a system or its component. A non-functional requirement defines the quality attribute of a software system.

It places constraints on “How should the software system fulfill the functional
It specifies “What should the software system do?”
requirements?”

Non-functional requirement is specified by technical peoples e.g. Architect, Technical

Functional requirement is specified by User.
leaders and software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of the software. Helps you to verify the performance of the software.

Functional Testing like System, Integration, End to End, API testing, etc are done. Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done.

Usually easy to define. Usually more difficult to define.

Example
Example
1) Authentication of user whenever he/she logs into the system.
1) Emails should be sent with a latency of no greater than 12 hours from such an activity.
2) System shutdown in case of a cyber attack.
2) The processing of each request should be done within 10 seconds
3) A Verification email is sent to user whenever he/she registers for the first time on some
3) The site should load in 3 seconds when the number of simultaneous users are > 10000
software system.
 Software requirement Specification (SRS)
• The production of the requirements stage of the software development process is Software Requirements Specifications
(SRS) (also called a requirements document).

• This report lays a foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed.

• SRS is a formal report, which acts as a representation of software that enables the customers to review whether it (SRS)
is according to their requirements.

• Also, it comprises user requirements for a system as well as detailed specifications of the system requirements.
 Software requirement Specification (SRS)
• The production of the requirements stage of the software
development process is Software Requirements Specifications
(SRS) (also called a requirements document).

• This report lays a foundation for software engineering activities

and is constructing when entire requirements are elicited and
analyzed.

• SRS is a formal report, which acts as a representation of software

that enables the customers to review whether it (SRS) is according
to their requirements.

• Also, it comprises user requirements for a system as well as

detailed specifications of the system requirements.
 Characteristics of good SRS
1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS. SRS is said to be perfect if it covers all t

2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data
in all available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
 Characteristics of good SRS
3. Consistency:

The SRS is consistent if, and only if, no subset of individual requirements described in its conflict.

There are three types of possible conflict in the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but in another as textual.

(b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-occurs.

4. Unambiguousness:

SRS is unambiguous when every fixed requirement has only one interpretation.

This suggests that each element is uniquely interpreted.

In case there is a method used with multiple definitions, the requirements report should determine the implications in the
SRS so that it is clear and simple to understand.
 Characteristics of good SRS
5. Ranking for importance and stability:

• The SRS is ranked for importance and stability if each requirement in it has an identifier to indicate either the
significance or stability of that particular requirement.

• Typically, all requirements are not equally important. Some prerequisites may be essential, especially for life-critical
applications, while others may be desirable.

• Each element should be identified to make these differences clear and explicit.

• Another way to rank requirements is to distinguish classes of items as essential, conditional, and optional.

6. Modifiability:

• SRS should be made as modifiable as likely and should be capable of quickly obtain changes to the system to some
extent. Modifications should be perfectly indexed and cross-referenced.
 Characteristics of good SRS
7. Verifiability:

SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final
software meets those requirements.

The requirements are verified with the help of reviews.

8. Traceability:

The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition
in future development or enhancement documentation.

There are two types of Traceability:

1. Backward Traceability:

This depends upon each requirement explicitly referencing its source in earlier documents.
2. Forward Traceability:

This depends upon each element in the SRS having a unique name or reference number.

The forward traceability of the SRS is especially crucial when the software product enters the operation and maintenance
 Characteristics of good SRS
10. Testability:

• An SRS should be written in such a method that it is simple to generate test cases and test plans from the report.

11. Understandable by the customer:

• An end user may be an expert in his/her explicit domain but might not be trained in computer science.

• Hence, the purpose of formal notations and symbols should be avoided too as much extent as possible.

• The language should be kept simple and clear.

12. The right level of abstraction:

• If the SRS is written for the requirements stage, the details should be explained explicitly.

• Whereas for a feasibility study, fewer analysis can be used.

• Hence, the level of abstraction modifies according to the objective of the SRS.
 Characteristics of good SRS
10. Testability:

• An SRS should be written in such a method that it is simple to generate test cases and test plans from the report.

11. Understandable by the customer:

• An end user may be an expert in his/her explicit domain but might not be trained in computer science.

• Hence, the purpose of formal notations and symbols should be avoided too as much extent as possible.

• The language should be kept simple and clear.

12. The right level of abstraction:

• If the SRS is written for the requirements stage, the details should be explained explicitly.

• Whereas for a feasibility study, fewer analysis can be used.

• Hence, the level of abstraction modifies according to the objective of the SRS.