SlideShare a Scribd company logo

Requirement Engineering. Types of requirement

Download as PPTX, PDF
D
DeepakUlape2

The document provides a comprehensive overview of requirement engineering, detailing types of requirements (functional and non-functional), four phases of the requirement engineering process (feasibility study, requirements elicitation, requirements specification, and verification/validation), and the structure of software requirements specification (SRS). It emphasizes the importance of clearly defining and documenting requirements to ensure successful software development and mentions the IEEE standard format for SRS. Additionally, it touches on agile methodologies, including the software development life cycle and principles of adaptive software development.

Software
1 of 43
Download to read offline
1
2
Most read
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Most read
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Module-2 Requirement Engineering Mr. Deepak V Ulape. (Assistant Professor) (8793536185)
2.1 Requirement Engineering • 2.1.1 Types of Requirements – Functional and Nonfunctional • 2 .1.2 Four Phases of Requirement Engineering • 2.1.3 Software requirement Specification (SRS) • 2.2.4Structure and contents of SRS • 2.1.5IEEE standard format for SRS
2.1.1 Types of Requirements – Functional and Nonfunctional • 1. Functional Requirements • Definition: Functional requirements describe what the software should do. They define the functions or features that the system must have. Examples: • User Authentication: The system must allow users to log in using a username and password. • Search Functionality: The software should enable users to search for products by name or category. • Report Generation: The system should be able to generate sales reports for a specified date range. • Explanation: Functional requirements specify the actions that the software needs to perform. These are the basic features and functionalities that users expect from the software.
2. Non-functional Requirements • Definition: Non-functional requirements describe how the software performs a task rather than what it should do. They define the quality attributes, performance criteria, and constraints. • Examples: • Performance: The system should process 1,000 transactions per second. • Usability: The software should be easy to use and have a user- friendly interface. • Reliability: The system must have 99.9% uptime. • Security: Data must be encrypted during transmission and storage. • Explanation: Non-functional requirements are about the system’s behavior, quality, and constraints. They ensure that the software meets certain standards of performance, usability, reliability, and security.
Four Phases of Requirement Engineering
1. Feasibility Study • A feasibility study is an assessment of the practicality of a proposed plan or project. It analyzes the viability of the project to determine whether it is likely to succeed and identifies potential issues and problems that could arise during its execution
Feasibility Study types: 1.Technical Feasibility: In Technical Feasibility current resources both hardware software along required technology are analyzed/assessed to develop the project. This technical feasibility study reports whether there are correct required resources and technologies that will be used for project development. Along with this, the feasibility study also analyzes the technical skills and capabilities of the technical team, whether existing technology can be used or not, whether maintenance and up-gradation are easy or not for the chosen technology, etc. 2.Operational Feasibility: In Operational Feasibility degree of providing service to requirements is analyzed along with how easy the product will be to operate and maintain after deployment. Along with this other operational scopes are determining the usability of the product, Determining suggested solution by the software development team is acceptable or not, etc. 3.Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are analyzed. This means under this feasibility study a detailed analysis is carried out will be cost of the project for development which includes all required costs for final development hardware and software resources required, design and development costs operational costs, and so on.
2. Requirements Elicitation • It is related to the various ways used to gain knowledge about the project domain and requirements. • The various sources of domain knowledge include customers, business manuals, the existing software of the same type, standards, and other stakeholders of the project. • The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc.. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage. • Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders for a software system. This is the first step in the requirements engineering process and it is critical to the success of the software development project. The goal of this step is to understand the problem that the software system is intended to solve and the needs and expectations of the stakeholders who will use the system.
3. Requirements Specification • This activity is used to produce formal software requirement models. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality. 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. • Requirements specification is the process of documenting the requirements identified in the analysis step in a clear, consistent, and unambiguous manner. This step also involves prioritizing and grouping the requirements into manageable chunks. • The goal of this step is to create a clear and comprehensive document that describes the requirements for the software system. This document should be understandable by both the development team and the stakeholders.
4. Requirements Verification and Validation • Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function. • Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework. The main steps for this process include: 1.The requirements should be consistent with all the other requirements i.e. no two requirements should conflict with each other. 2.The requirements should be complete in every sense. 3.The requirements should be practically achievable.
Software Requirement Specification (SRS) • 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.
Requirement Engineering. Types of requirement
Introduction • Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose of document is explained and described. • Scope of this document – In this, overall working and main objective of document and what value it will provide to customer is described and explained. It also includes a description of development cost and time required. • Overview – In this, description of product is explained. It’s simply summary or overall review of product. • General description • In this, general functions of product which includes objective of user, a user characteristic, features, benefits, about why its importance is mentioned. It also describes features of user community.
• Functional Requirements • In this, possible outcome of software system which includes effects due to operation of program is fully explained. All functional requirements which may include calculations, data processing, etc. are placed in a ranked order. Functional requirements specify the expected behavior of the system-which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system. For each functional requirement, detailed description all the data inputs and their source, the units of measure, and the range of valid inputs must be specified. • Interface Requirements • In this, software interfaces which mean how software program communicates with each other or users either in form of any language, code, or message are fully described and explained. Examples can be shared memory, data streams, etc. • Performance Requirements • In this, how a software system performs desired functions under specific condition is explained. It also explains required time, required memory, maximum error rate, etc. The performance requirements part of an SRS specifies the performance constraints on the software system. All the requirements relating to the performance characteristics of the system must be clearly specified. There are two types of performance requirements: static and dynamic. Static requirements are those that do not impose constraint on the execution characteristics of the system. Dynamic requirements specify constraints on the execution behaviour of the system.
Design Constraints • In this, constraints which simply means limitation or restriction are specified and explained for design team. Examples may include use of a particular algorithm, hardware and software limitations, etc. There are a number of factors in the client’s environment that may restrict the choices of a designer leading to design constraints such factors include standards that must be followed resource limits, operating environment, reliability and security requirements and policies that may have an impact on the design of the system. An SRS should identify and specify all such constraints.
• Non-Functional Attributes • In this, non-functional attributes are explained that are required by software system for better performance. An example may include Security, Portability, Reliability, Reusability, Application compatibility, Data integrity, Scalability capacity, etc. • Preliminary Schedule and Budget • In this, initial version and budget of project plan are explained which include overall time duration required and overall cost required for development of project. • Appendices • In this, additional information like references from where information is gathered, definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.
Uses of SRS document • Development team require it for developing product according to the need. • Test plans are generated by testing group based on the describe external behaviour. • Maintenance and support staff need it to understand what the software product is supposed to do. • Project manager base their plans and estimates of schedule, effort and resources on it. • customer rely on it to know that product they can expect. • As a contract between developer and customer. • in documentation purpose.
IEEE standard format for SRS • The IEEE (Institute of Electrical and Electronics Engineers) standard for Software Requirements Specifications (SRS) is defined in IEEE 830-1998, titled "IEEE Recommended Practice for Software Requirements Specifications." This standard provides a structured approach to documenting the requirements for a software system. • 1. Introduction - 1.1 Purpose: Defines the purpose of the SRS and the intended audience. - 1.2 Scope: Outlines the software product to be specified, including its boundaries, major features, and goals. - 1.3 Definitions, Acronyms, and Abbreviations: Provides definitions for terms, acronyms, and abbreviations used in the SRS. - 1.4 References: Lists any references to other documents or standards that are pertinent to the SRS. - 1.5 Overview: Gives an overview of the remaining sections of the SRS.
2. Overall Description - 2.1 Product Perspective: Describes the context and origin of the product, including its relationship to other systems. - 2.2 Product Functions: Provides a high-level summary of the software’s functions. - 2.3 User Classes and Characteristics: Identifies the different user types and their needs. - 2.4 Operating Environment: Specifies the hardware, software, and other environmental constraints. - 2.5 Design and Implementation Constraints: Lists any constraints on design and implementation. - 2.6 User Documentation: Details the documentation and training materials provided to users. - 2.7 Assumptions and Dependencies: Describes any assumptions and dependencies that could impact the software requirements.
3. Specific Requirements - 3.1 Functional Requirements: Provides detailed descriptions of the functions the software must perform. - 3.2 External Interface Requirements: Details interactions between the software and other systems or users. - 3.2.1 User Interfaces: Specifies the user interface requirements. - 3.2.2 Hardware Interfaces: Describes the hardware interfaces if applicable. - 3.2.3 Software Interfaces: Outlines any software interfaces. - 3.2.4 Communications Interfaces: Defines the communication protocols and standards. - 3.3 Performance Requirements: Specifies performance constraints and criteria. - 3.4 Design Constraints: Describes constraints related to the design of the software. - 3.5 Software System Attributes: Details attributes such as reliability, availability, security, and maintainability. - 3.6 Other Requirements: Includes any other requirements not covered in the above sections.
4. Appendices - 4.1 Glossary: Provides a glossary of terms used in the SRS. - 4.2 Analysis Models: Includes diagrams and models that support the requirements, such as data flow diagrams or use case diagrams. - 4.3 Issue Tracking: Optional section for tracking unresolved issues or changes.
Introduction to Web Engineering : • Web Engineering is a discipline that focuses on the design, development, and maintenance of web applications and systems. It combines principles from computer science, software engineering, and web development to create robust, scalable, and user-friendly web solutions.
Agile Methodology • The Agile methodology is a project management and software development approach that emphasizes flexibility, collaboration, and customer-centricity. It is the latest model used by major companies today like Facebook, google, amazon, etc. • Agile is a project management and software development approach that aims to be more effective. 1.It focuses on delivering smaller pieces of work regularly instead of one big launch. 2.This allows teams to adapt to changes quickly and provide customer value faster.
• Agile methodologies are iterative and incremental, which means it’s known for breaking a project into smaller parts and adjusting to changing requirements. 1.They prioritize flexibility, collaboration, and customer satisfaction. 2.Major companies like Facebook, Google, and Amazon use Agile because of its adaptability and customer-focused approach.
Life cycle of Agile Methodology The Agile software development life cycle helps you break down each project you take on into six simple stages:
• 1. Requirement Gathering • In this stage, the project team identifies and documents the needs and expectations of various stakeholders, including clients, users, and subject matter experts. • It involves defining the project’s scope, objectives, and requirements. • Establishing a budget and schedule. • Creating a project plan and allocating resources. • 2. Design • Developing a high-level system architecture. • Creating detailed specifications, which include data structures, algorithms, and interfaces. • Planning for the software’s user interface.
3. Development (Coding) Writing the actual code for the software. Conducting unit testing to verify the functionality of individual components. 4. Testing This phase involves several types of testing: Integration Testing: Ensuring that different components work together. System Testing: Testing the entire system as a whole. User Acceptance Testing: Confirming that the software meets user requirements. Performance Testing: Assessing the system’s speed, scalability, and stability. 5. Deployment Deploying the software to a production environment. Put the software into the real world where people can use it. Make sure it works smoothly in the real world. Providing training and support for end-users.
6. Review (Maintenance) Addressing and resolving any issues that may arise after deployment. Releasing updates and patches to enhance the software and address problems.
Adaptive Software Development (ASD) is a software development methodologythat emphasizes adaptability to respond to changing requirements and environments. It focuses on continuous learning and is considered a part of agile software development. 1.Iterative Development: ASD breaks down the project into small, manageable iterations, delivering incremental values. 2.Risk Management: ASD involves identifying and addressing risks early in the development process. 3.Continuous Testing: It integrates testing throughout the development process to ensure high-quality outcomes. 4.Decentralized Control: It encourages decision-making at the team level instead of relying on top-down directives. 5.Customer Satisfaction: It prioritizes customer satisfaction by delivering products that meet their needs and expectations.
Characteristics of ASD Process principles of ASD that distinguish it from more traditional, plan-driven methodologies: 1.Adaptability: ASD focuses on high-level adaptive planning instead of detailed, fixed plans. 2.Collaborative Environment: In ASD, a strong focus is on collaboration within the team, thus promoting a culture of open communication. 3.Continuous Learning: It emphasizes learning from each iteration and using feedback to improve the process and the product. 4.Iterative Development: In ASD, the development is broken into small, manageable increments. Each increment delivers a piece of functional software. 5.Responsive to Change: It allows the project to quickly adapt to the changes in requirements, technology, and market conditions.
Phases of ASD Process ASD life cycle incorporates three phases namely: 1.Speculation 2.Collaboration 3.Learning These are explained below:
1. Speculation During this phase project is initiated and planning is conducted. The project plan uses project initiation information like project requirements, user needs, customer mission statement, etc, to define a set of release cycles that the project wants. 2. Collaboration It is the difficult part of ASD as it needs the workers to be motivated. It collaborates communication and teamwork but emphasizes individualism as individual creativity plays a major role in creative thinking. People working together must trust each other to Criticize without animosity, Assist without resentment, Work as hard as possible, Possession of skill set, Communicate problems to find effective solutions.
3. Learning The workers may have an overestimate of their understanding of the technology which may not lead to the desired result. Learning helps the workers to increase their level of understanding of the project. The learning process is in 3 ways: 1.Focus groups 2.Technical reviews 3.Project postmortem
Strengths of ASD key strengths of Adaptive Software Development (ASD): 1.Customer Focus: Regular and active involvement of customers to make sure that the product meets their needs and expectations. 2.Continuous Delivery: Delivering functional software in small, manageable increments allows for early and continuous delivery of value. 3.Early Problem Detection: Regular testing and releases help to identify and resolve issues early in the development process. 4.Strong Teamwork: Emphasizes teamwork among the team members, thus fostering a supportive environment.
Weakness of ASD weaknesses of Adaptive Software Development (ASD): 1.Requires High Level of Skill: Successful implementation of ASD requires a team with a high-level of skill, experience, and familiarity with the agile principles. 2.Changing Requirements: The flexible nature of ASD may result in frequent changes of requirements, which might result in scope creep if it is not managed properly. 3.Customer Availability: ASD relies heavily on active and continuous customer participation, which can be difficult to achieve in cases when the customer is not fully engaged or not available. 4.Uncertain Project Outcomes: The iterative and adaptive nature of ASD makes it difficult to predict the outcome of the project.
• The Dynamic Systems Development technique (DSDM) is an associate degree agile code development approach that provides a framework for building and maintaining systems. The DSDM philosophy is borrowed from a modified version of the sociologist principle—80 % of An application is often delivered in twenty percent of the time it’d desire deliver the entire (100 percent) application. • DSDM is An iterative code method within which every iteration follows the 80% rule that simply enough work is needed for every increment to facilitate movement to the following increment. The remaining detail is often completed later once a lot of business necessities are noted or changes are requested and accommodated.
scrum in software development: • Scrum is a management framework that teams use to self- organize tasks and work towards a common goal. It is a framework within which people can address complex adaptive problems while the productivity and creativity of delivering products are at the highest possible value. Scrum is a management framework that teams use to self-organize and work towards a common goal. • Scrum allows us to develop products of the highest value while making sure that we maintain creativity and productivity. • The iterative and incremental approach used in scrum allows the teams to adapt to the changing requirements.
Silent features of Scrum • Scrum is a light-weighted framework • Scrum emphasizes self-organization • Scrum is simple to understand • Scrum framework helps the team to work together • Lifecycle of Scrum
Requirement Engineering. Types of requirement
• Sprint: A Sprint is a time box of one month or less. A new Sprint starts immediately after the completion of the previous Sprint. Release: When the product is completed, it goes to the Release stage. • Sprint Review: If the product still has some non-achievable features, it will be checked in this stage and then passed to the Sprint Retrospective stage. • Sprint Retrospective: In this stage quality or status of the product is checked. Product Backlog: According to the prioritize features the product is organized. • Sprint Backlog: Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning meeting.
Advantage of Scrum framework • Scrum framework is fast moving and money efficient. • Scrum framework works by dividing the large product into small sub-products. It’s like a divide and conquer strategy • In Scrum customer satisfaction is very important. • Scrum is adaptive in nature because it have short sprint. • As Scrum framework rely on constant feedback therefore the quality of product increases in less amount of time
Disadvantage of Scrum framework : • Scrum framework do not allow changes into their sprint. • Scrum framework is not fully described model. If you wanna adopt it you need to fill in the framework with your own details like Extreme Programming(XP), Kanban, Dynamic Systems Development Method (DSDM). • It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear definition. • The daily Scrum meetings and frequent reviews require substantial resources.
Requirement Engineering. Types of requirement

More Related Content

PPTX
SE Unit 2(1).pptx
aryan631999
 
PDF
SE-Unit II.pdf
AMITKUMARSINGH756828
 
PPTX
Software engineering Unit 2(Updated)2.pptx
singhpriyansh0510
 
PPTX
Software Engineering Notes Unit - 1.pptx
rahatansari3
 
PDF
9-Requirements Engineering process, Requirement Elicitation-21-01-2025.pdf
UjjwalAgrawal34
 
PPTX
Software Requirements
Nethan Shaik
 
PPTX
Unit 2 Requirement Elicitation, Analysis, and Specification.pptx
reallifeidiota
 
PPTX
Software Engineering Unit 2 AKTU Complete
malviyamishra19
 
SE Unit 2(1).pptx
aryan631999
 
SE-Unit II.pdf
AMITKUMARSINGH756828
 
Software engineering Unit 2(Updated)2.pptx
singhpriyansh0510
 
Software Engineering Notes Unit - 1.pptx
rahatansari3
 
9-Requirements Engineering process, Requirement Elicitation-21-01-2025.pdf
UjjwalAgrawal34
 
Software Requirements
Nethan Shaik
 
Unit 2 Requirement Elicitation, Analysis, and Specification.pptx
reallifeidiota
 
Software Engineering Unit 2 AKTU Complete
malviyamishra19
 

Similar to Requirement Engineering. Types of requirement (20)

PPTX
Development Guideline
Mohammad Nasir Uddin
 
PDF
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
Jayanthi Kannan MK
 
PPSX
Introduction to Requirement engineering
Nameirakpam Sundari
 
PPTX
SRE_Lecture_1,2,3,4.pptx
AlideveroMurtaza
 
PPTX
SOFTWARE ENGINEERING FOR BCA DEGREE STUDENTS
VanadhiSathyasekar
 
PPTX
04 fse understandingrequirements
Mohesh Chandran
 
PPTX
Introduction to Software Engineering Notes.pptx
bscit6
 
PPTX
2.1. SW Requirements n Specifications.pptx
dawarbaba
 
PPTX
SF 9_Unit 2.pptx software engineering ppt
AmarrKannthh
 
PPT
Software Engineering Lec 4-requirments
Taymoor Nazmy
 
PPTX
requirement Engineeringggggggggggggggggg
pspreeti916
 
PDF
CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE ...
ps805094
 
PDF
3. 1 req elicitation
Ashenafi Workie
 
PDF
Software requirements specifications documents pdf
Nothing807440
 
PPTX
Requirement engineering
Benazir Fathima
 
PPTX
sdlc.pptx
XylemSolutions
 
PPTX
1602984149-1-introduction.pptx4hjdqehjeg
faiziikanwal47
 
PPTX
Soft requirement
Rishav Upreti
 
DOCX
FOUNDATION SKILLS INTERGRATED PRODUCT DEVELOPMENT
jananikumaravell1
 
PDF
2-Reqerwsrhfdfsfgtdrttddjdiuiversion 2.pdf
FadyFady9
 
Development Guideline
Mohammad Nasir Uddin
 
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
Jayanthi Kannan MK
 
Introduction to Requirement engineering
Nameirakpam Sundari
 
SRE_Lecture_1,2,3,4.pptx
AlideveroMurtaza
 
SOFTWARE ENGINEERING FOR BCA DEGREE STUDENTS
VanadhiSathyasekar
 
04 fse understandingrequirements
Mohesh Chandran
 
Introduction to Software Engineering Notes.pptx
bscit6
 
2.1. SW Requirements n Specifications.pptx
dawarbaba
 
SF 9_Unit 2.pptx software engineering ppt
AmarrKannthh
 
Software Engineering Lec 4-requirments
Taymoor Nazmy
 
requirement Engineeringggggggggggggggggg
pspreeti916
 
CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE ...
ps805094
 
3. 1 req elicitation
Ashenafi Workie
 
Software requirements specifications documents pdf
Nothing807440
 
Requirement engineering
Benazir Fathima
 
sdlc.pptx
XylemSolutions
 
1602984149-1-introduction.pptx4hjdqehjeg
faiziikanwal47
 
Soft requirement
Rishav Upreti
 
FOUNDATION SKILLS INTERGRATED PRODUCT DEVELOPMENT
jananikumaravell1
 
2-Reqerwsrhfdfsfgtdrttddjdiuiversion 2.pdf
FadyFady9
 
Ad

Recently uploaded (20)

PDF
Nekopoi APK 2025 free lastest update
umarali35kp
 
PPTX
L1 - Introduction to python Backend.pptx
MoizAhmed480282
 
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
Aetos Technologies
 
PPTX
VVF-Customer-Presentation2025-Ver1.9.pptx
blackmambaettijean
 
PDF
Softaken Excel to vCard Converter Software.pdf
markwillsonmw004
 
PDF
System and Network Administration Chapter 2
jaramharo
 
PDF
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
PPTX
Online Work Permit System for Fast Permit Processing
SHEQ Network Limited
 
PDF
Adobe Illustrator 28.6 Crack My Vision of Vector Design
ghrom2211g
 
PDF
Navsoft: AI-Powered Business Solutions & Custom Software Development
Navsoft
 
PDF
How to Migrate SBCGlobal Email to Yahoo Easily
raymondjones7273
 
PDF
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
lawrenceomai2
 
PDF
top salesforce developer skills in 2025.pdf
CloudMetic
 
PDF
AI in Product Development-omnex systems
omnex systems
 
PDF
System and Network Administraation Chapter 3
jaramharo
 
PPTX
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
hci7se
 
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
PDF
Upgrade and Innovation Strategies for SAP ERP Customers
Virendra Rai, PMP
 
PDF
PTS Company Brochure 2025 (1).pdf.......
pts464036
 
PPT
Introduction Database Management System for Course Database
ReinertYosua
 
Nekopoi APK 2025 free lastest update
umarali35kp
 
L1 - Introduction to python Backend.pptx
MoizAhmed480282
 
2025 Textile ERP Trends: SAP, Odoo & Oracle
Aetos Technologies
 
VVF-Customer-Presentation2025-Ver1.9.pptx
blackmambaettijean
 
Softaken Excel to vCard Converter Software.pdf
markwillsonmw004
 
System and Network Administration Chapter 2
jaramharo
 
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
Online Work Permit System for Fast Permit Processing
SHEQ Network Limited
 
Adobe Illustrator 28.6 Crack My Vision of Vector Design
ghrom2211g
 
Navsoft: AI-Powered Business Solutions & Custom Software Development
Navsoft
 
How to Migrate SBCGlobal Email to Yahoo Easily
raymondjones7273
 
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
lawrenceomai2
 
top salesforce developer skills in 2025.pdf
CloudMetic
 
AI in Product Development-omnex systems
omnex systems
 
System and Network Administraation Chapter 3
jaramharo
 
Lecture 3: Operating Systems Introduction to Computer Hardware Systems
hci7se
 
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
Upgrade and Innovation Strategies for SAP ERP Customers
Virendra Rai, PMP
 
PTS Company Brochure 2025 (1).pdf.......
pts464036
 
Introduction Database Management System for Course Database
ReinertYosua
 
Ad

Requirement Engineering. Types of requirement

  • 1. Module-2 Requirement Engineering Mr. Deepak V Ulape. (Assistant Professor) (8793536185)
  • 2. 2.1 Requirement Engineering • 2.1.1 Types of Requirements – Functional and Nonfunctional • 2 .1.2 Four Phases of Requirement Engineering • 2.1.3 Software requirement Specification (SRS) • 2.2.4Structure and contents of SRS • 2.1.5IEEE standard format for SRS
  • 3. 2.1.1 Types of Requirements – Functional and Nonfunctional • 1. Functional Requirements • Definition: Functional requirements describe what the software should do. They define the functions or features that the system must have. Examples: • User Authentication: The system must allow users to log in using a username and password. • Search Functionality: The software should enable users to search for products by name or category. • Report Generation: The system should be able to generate sales reports for a specified date range. • Explanation: Functional requirements specify the actions that the software needs to perform. These are the basic features and functionalities that users expect from the software.
  • 4. 2. Non-functional Requirements • Definition: Non-functional requirements describe how the software performs a task rather than what it should do. They define the quality attributes, performance criteria, and constraints. • Examples: • Performance: The system should process 1,000 transactions per second. • Usability: The software should be easy to use and have a user- friendly interface. • Reliability: The system must have 99.9% uptime. • Security: Data must be encrypted during transmission and storage. • Explanation: Non-functional requirements are about the system’s behavior, quality, and constraints. They ensure that the software meets certain standards of performance, usability, reliability, and security.
  • 5. Four Phases of Requirement Engineering
  • 6. 1. Feasibility Study • A feasibility study is an assessment of the practicality of a proposed plan or project. It analyzes the viability of the project to determine whether it is likely to succeed and identifies potential issues and problems that could arise during its execution
  • 7. Feasibility Study types: 1.Technical Feasibility: In Technical Feasibility current resources both hardware software along required technology are analyzed/assessed to develop the project. This technical feasibility study reports whether there are correct required resources and technologies that will be used for project development. Along with this, the feasibility study also analyzes the technical skills and capabilities of the technical team, whether existing technology can be used or not, whether maintenance and up-gradation are easy or not for the chosen technology, etc. 2.Operational Feasibility: In Operational Feasibility degree of providing service to requirements is analyzed along with how easy the product will be to operate and maintain after deployment. Along with this other operational scopes are determining the usability of the product, Determining suggested solution by the software development team is acceptable or not, etc. 3.Economic Feasibility: In the Economic Feasibility study cost and benefit of the project are analyzed. This means under this feasibility study a detailed analysis is carried out will be cost of the project for development which includes all required costs for final development hardware and software resources required, design and development costs operational costs, and so on.
  • 8. 2. Requirements Elicitation • It is related to the various ways used to gain knowledge about the project domain and requirements. • The various sources of domain knowledge include customers, business manuals, the existing software of the same type, standards, and other stakeholders of the project. • The techniques used for requirements elicitation include interviews, brainstorming, task analysis, Delphi technique, prototyping, etc.. Elicitation does not produce formal models of the requirements understood. Instead, it widens the domain knowledge of the analyst and thus helps in providing input to the next stage. • Requirements elicitation is the process of gathering information about the needs and expectations of stakeholders for a software system. This is the first step in the requirements engineering process and it is critical to the success of the software development project. The goal of this step is to understand the problem that the software system is intended to solve and the needs and expectations of the stakeholders who will use the system.
  • 9. 3. Requirements Specification • This activity is used to produce formal software requirement models. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality. 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. • Requirements specification is the process of documenting the requirements identified in the analysis step in a clear, consistent, and unambiguous manner. This step also involves prioritizing and grouping the requirements into manageable chunks. • The goal of this step is to create a clear and comprehensive document that describes the requirements for the software system. This document should be understandable by both the development team and the stakeholders.
  • 10. 4. Requirements Verification and Validation • Verification: It refers to the set of tasks that ensures that the software correctly implements a specific function. • Validation: It refers to a different set of tasks that ensures that the software that has been built is traceable to customer requirements. If requirements are not validated, errors in the requirement definitions would propagate to the successive stages resulting in a lot of modification and rework. The main steps for this process include: 1.The requirements should be consistent with all the other requirements i.e. no two requirements should conflict with each other. 2.The requirements should be complete in every sense. 3.The requirements should be practically achievable.
  • 11. Software Requirement Specification (SRS) • 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.
  • 13. Introduction • Purpose of this Document – At first, main aim of why this document is necessary and what’s purpose of document is explained and described. • Scope of this document – In this, overall working and main objective of document and what value it will provide to customer is described and explained. It also includes a description of development cost and time required. • Overview – In this, description of product is explained. It’s simply summary or overall review of product. • General description • In this, general functions of product which includes objective of user, a user characteristic, features, benefits, about why its importance is mentioned. It also describes features of user community.
  • 14. • Functional Requirements • In this, possible outcome of software system which includes effects due to operation of program is fully explained. All functional requirements which may include calculations, data processing, etc. are placed in a ranked order. Functional requirements specify the expected behavior of the system-which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system. For each functional requirement, detailed description all the data inputs and their source, the units of measure, and the range of valid inputs must be specified. • Interface Requirements • In this, software interfaces which mean how software program communicates with each other or users either in form of any language, code, or message are fully described and explained. Examples can be shared memory, data streams, etc. • Performance Requirements • In this, how a software system performs desired functions under specific condition is explained. It also explains required time, required memory, maximum error rate, etc. The performance requirements part of an SRS specifies the performance constraints on the software system. All the requirements relating to the performance characteristics of the system must be clearly specified. There are two types of performance requirements: static and dynamic. Static requirements are those that do not impose constraint on the execution characteristics of the system. Dynamic requirements specify constraints on the execution behaviour of the system.
  • 15. Design Constraints • In this, constraints which simply means limitation or restriction are specified and explained for design team. Examples may include use of a particular algorithm, hardware and software limitations, etc. There are a number of factors in the client’s environment that may restrict the choices of a designer leading to design constraints such factors include standards that must be followed resource limits, operating environment, reliability and security requirements and policies that may have an impact on the design of the system. An SRS should identify and specify all such constraints.
  • 16. • Non-Functional Attributes • In this, non-functional attributes are explained that are required by software system for better performance. An example may include Security, Portability, Reliability, Reusability, Application compatibility, Data integrity, Scalability capacity, etc. • Preliminary Schedule and Budget • In this, initial version and budget of project plan are explained which include overall time duration required and overall cost required for development of project. • Appendices • In this, additional information like references from where information is gathered, definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.
  • 17. Uses of SRS document • Development team require it for developing product according to the need. • Test plans are generated by testing group based on the describe external behaviour. • Maintenance and support staff need it to understand what the software product is supposed to do. • Project manager base their plans and estimates of schedule, effort and resources on it. • customer rely on it to know that product they can expect. • As a contract between developer and customer. • in documentation purpose.
  • 18. IEEE standard format for SRS • The IEEE (Institute of Electrical and Electronics Engineers) standard for Software Requirements Specifications (SRS) is defined in IEEE 830-1998, titled "IEEE Recommended Practice for Software Requirements Specifications." This standard provides a structured approach to documenting the requirements for a software system. • 1. Introduction - 1.1 Purpose: Defines the purpose of the SRS and the intended audience. - 1.2 Scope: Outlines the software product to be specified, including its boundaries, major features, and goals. - 1.3 Definitions, Acronyms, and Abbreviations: Provides definitions for terms, acronyms, and abbreviations used in the SRS. - 1.4 References: Lists any references to other documents or standards that are pertinent to the SRS. - 1.5 Overview: Gives an overview of the remaining sections of the SRS.
  • 19. 2. Overall Description - 2.1 Product Perspective: Describes the context and origin of the product, including its relationship to other systems. - 2.2 Product Functions: Provides a high-level summary of the software’s functions. - 2.3 User Classes and Characteristics: Identifies the different user types and their needs. - 2.4 Operating Environment: Specifies the hardware, software, and other environmental constraints. - 2.5 Design and Implementation Constraints: Lists any constraints on design and implementation. - 2.6 User Documentation: Details the documentation and training materials provided to users. - 2.7 Assumptions and Dependencies: Describes any assumptions and dependencies that could impact the software requirements.
  • 20. 3. Specific Requirements - 3.1 Functional Requirements: Provides detailed descriptions of the functions the software must perform. - 3.2 External Interface Requirements: Details interactions between the software and other systems or users. - 3.2.1 User Interfaces: Specifies the user interface requirements. - 3.2.2 Hardware Interfaces: Describes the hardware interfaces if applicable. - 3.2.3 Software Interfaces: Outlines any software interfaces. - 3.2.4 Communications Interfaces: Defines the communication protocols and standards. - 3.3 Performance Requirements: Specifies performance constraints and criteria. - 3.4 Design Constraints: Describes constraints related to the design of the software. - 3.5 Software System Attributes: Details attributes such as reliability, availability, security, and maintainability. - 3.6 Other Requirements: Includes any other requirements not covered in the above sections.
  • 21. 4. Appendices - 4.1 Glossary: Provides a glossary of terms used in the SRS. - 4.2 Analysis Models: Includes diagrams and models that support the requirements, such as data flow diagrams or use case diagrams. - 4.3 Issue Tracking: Optional section for tracking unresolved issues or changes.
  • 22. Introduction to Web Engineering : • Web Engineering is a discipline that focuses on the design, development, and maintenance of web applications and systems. It combines principles from computer science, software engineering, and web development to create robust, scalable, and user-friendly web solutions.
  • 23. Agile Methodology • The Agile methodology is a project management and software development approach that emphasizes flexibility, collaboration, and customer-centricity. It is the latest model used by major companies today like Facebook, google, amazon, etc. • Agile is a project management and software development approach that aims to be more effective. 1.It focuses on delivering smaller pieces of work regularly instead of one big launch. 2.This allows teams to adapt to changes quickly and provide customer value faster.
  • 24. • Agile methodologies are iterative and incremental, which means it’s known for breaking a project into smaller parts and adjusting to changing requirements. 1.They prioritize flexibility, collaboration, and customer satisfaction. 2.Major companies like Facebook, Google, and Amazon use Agile because of its adaptability and customer-focused approach.
  • 25. Life cycle of Agile Methodology The Agile software development life cycle helps you break down each project you take on into six simple stages:
  • 26. • 1. Requirement Gathering • In this stage, the project team identifies and documents the needs and expectations of various stakeholders, including clients, users, and subject matter experts. • It involves defining the project’s scope, objectives, and requirements. • Establishing a budget and schedule. • Creating a project plan and allocating resources. • 2. Design • Developing a high-level system architecture. • Creating detailed specifications, which include data structures, algorithms, and interfaces. • Planning for the software’s user interface.
  • 27. 3. Development (Coding) Writing the actual code for the software. Conducting unit testing to verify the functionality of individual components. 4. Testing This phase involves several types of testing: Integration Testing: Ensuring that different components work together. System Testing: Testing the entire system as a whole. User Acceptance Testing: Confirming that the software meets user requirements. Performance Testing: Assessing the system’s speed, scalability, and stability. 5. Deployment Deploying the software to a production environment. Put the software into the real world where people can use it. Make sure it works smoothly in the real world. Providing training and support for end-users.
  • 28. 6. Review (Maintenance) Addressing and resolving any issues that may arise after deployment. Releasing updates and patches to enhance the software and address problems.
  • 29. Adaptive Software Development (ASD) is a software development methodologythat emphasizes adaptability to respond to changing requirements and environments. It focuses on continuous learning and is considered a part of agile software development. 1.Iterative Development: ASD breaks down the project into small, manageable iterations, delivering incremental values. 2.Risk Management: ASD involves identifying and addressing risks early in the development process. 3.Continuous Testing: It integrates testing throughout the development process to ensure high-quality outcomes. 4.Decentralized Control: It encourages decision-making at the team level instead of relying on top-down directives. 5.Customer Satisfaction: It prioritizes customer satisfaction by delivering products that meet their needs and expectations.
  • 30. Characteristics of ASD Process principles of ASD that distinguish it from more traditional, plan-driven methodologies: 1.Adaptability: ASD focuses on high-level adaptive planning instead of detailed, fixed plans. 2.Collaborative Environment: In ASD, a strong focus is on collaboration within the team, thus promoting a culture of open communication. 3.Continuous Learning: It emphasizes learning from each iteration and using feedback to improve the process and the product. 4.Iterative Development: In ASD, the development is broken into small, manageable increments. Each increment delivers a piece of functional software. 5.Responsive to Change: It allows the project to quickly adapt to the changes in requirements, technology, and market conditions.
  • 31. Phases of ASD Process ASD life cycle incorporates three phases namely: 1.Speculation 2.Collaboration 3.Learning These are explained below:
  • 32. 1. Speculation During this phase project is initiated and planning is conducted. The project plan uses project initiation information like project requirements, user needs, customer mission statement, etc, to define a set of release cycles that the project wants. 2. Collaboration It is the difficult part of ASD as it needs the workers to be motivated. It collaborates communication and teamwork but emphasizes individualism as individual creativity plays a major role in creative thinking. People working together must trust each other to Criticize without animosity, Assist without resentment, Work as hard as possible, Possession of skill set, Communicate problems to find effective solutions.
  • 33. 3. Learning The workers may have an overestimate of their understanding of the technology which may not lead to the desired result. Learning helps the workers to increase their level of understanding of the project. The learning process is in 3 ways: 1.Focus groups 2.Technical reviews 3.Project postmortem
  • 34. Strengths of ASD key strengths of Adaptive Software Development (ASD): 1.Customer Focus: Regular and active involvement of customers to make sure that the product meets their needs and expectations. 2.Continuous Delivery: Delivering functional software in small, manageable increments allows for early and continuous delivery of value. 3.Early Problem Detection: Regular testing and releases help to identify and resolve issues early in the development process. 4.Strong Teamwork: Emphasizes teamwork among the team members, thus fostering a supportive environment.
  • 35. Weakness of ASD weaknesses of Adaptive Software Development (ASD): 1.Requires High Level of Skill: Successful implementation of ASD requires a team with a high-level of skill, experience, and familiarity with the agile principles. 2.Changing Requirements: The flexible nature of ASD may result in frequent changes of requirements, which might result in scope creep if it is not managed properly. 3.Customer Availability: ASD relies heavily on active and continuous customer participation, which can be difficult to achieve in cases when the customer is not fully engaged or not available. 4.Uncertain Project Outcomes: The iterative and adaptive nature of ASD makes it difficult to predict the outcome of the project.
  • 36. • The Dynamic Systems Development technique (DSDM) is an associate degree agile code development approach that provides a framework for building and maintaining systems. The DSDM philosophy is borrowed from a modified version of the sociologist principle—80 % of An application is often delivered in twenty percent of the time it’d desire deliver the entire (100 percent) application. • DSDM is An iterative code method within which every iteration follows the 80% rule that simply enough work is needed for every increment to facilitate movement to the following increment. The remaining detail is often completed later once a lot of business necessities are noted or changes are requested and accommodated.
  • 37. scrum in software development: • Scrum is a management framework that teams use to self- organize tasks and work towards a common goal. It is a framework within which people can address complex adaptive problems while the productivity and creativity of delivering products are at the highest possible value. Scrum is a management framework that teams use to self-organize and work towards a common goal. • Scrum allows us to develop products of the highest value while making sure that we maintain creativity and productivity. • The iterative and incremental approach used in scrum allows the teams to adapt to the changing requirements.
  • 38. Silent features of Scrum • Scrum is a light-weighted framework • Scrum emphasizes self-organization • Scrum is simple to understand • Scrum framework helps the team to work together • Lifecycle of Scrum
  • 40. • Sprint: A Sprint is a time box of one month or less. A new Sprint starts immediately after the completion of the previous Sprint. Release: When the product is completed, it goes to the Release stage. • Sprint Review: If the product still has some non-achievable features, it will be checked in this stage and then passed to the Sprint Retrospective stage. • Sprint Retrospective: In this stage quality or status of the product is checked. Product Backlog: According to the prioritize features the product is organized. • Sprint Backlog: Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning meeting.
  • 41. Advantage of Scrum framework • Scrum framework is fast moving and money efficient. • Scrum framework works by dividing the large product into small sub-products. It’s like a divide and conquer strategy • In Scrum customer satisfaction is very important. • Scrum is adaptive in nature because it have short sprint. • As Scrum framework rely on constant feedback therefore the quality of product increases in less amount of time
  • 42. Disadvantage of Scrum framework : • Scrum framework do not allow changes into their sprint. • Scrum framework is not fully described model. If you wanna adopt it you need to fill in the framework with your own details like Extreme Programming(XP), Kanban, Dynamic Systems Development Method (DSDM). • It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear definition. • The daily Scrum meetings and frequent reviews require substantial resources.