SlideShare a Scribd company logo
1 of 34
Download to read offline
Requirements
Engineering
The process of establishing the services that the
customer requires from a system and the
constraints under which it operates and is
developed.
The requirements themselves are the descriptions of
the system services and constraints that are
generated during the requirements engineering
process.
2
Constraints
• Constraints are things that we live with in our daily lives,
accept them, and move on.
• Constraints are things that affect your product but are “out
of your control”.
• Careful planning, collaboration with internal and external
stakeholders, and holding yourself responsible for what you
say and do is the professional way of doing things.
• For example Economical Constraints, Managerial
Constraints, Technical Constraints, Social Constraints.
3
Types of Requirement
•User Requirements
Statements in natural language plus diagrams of the services
the system provides and its operational constraints.
Written for customers. For E.g. User Interface, Natural
language etc.
•System Requirements
A structured document setting out detailed descriptions of
the system’s functions, services and operational constraints.
For E.g. Generating Sales Report, Customers data etc.
Defines what should be implemented?
4
Functional and Non-Functional
Requirements
• Functional requirements
• Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave
in particular situations.
• May state what the system should not do.
• Non-functional requirements
•Constraints on the services or functions offered by the system such
as timing constraints, constraints on the development process,
standards, etc.
• Domain requirements
• Constraints on the system from the domain of operation
5
Requirements Engineering
Requirements engineering tasks:
- Inception
- Elicitation
- Elaboration
- Negotiation
- Specification
- Validation
- Requirements Management
The Problems with our
Requirements Practices
•We have trouble understanding the requirements
that we do acquire from the customer
•We often record requirements in a disorganized
manner
•We spend far too little time verifying what we do
record
•Most importantly, we fail to establish a solid
foundation for the system or software that the
user wants built
7
(more on next slide)
The Problems with our Requirements
Practices (continued)
• Many software developers argue that
• Building software is so compelling that we want to jump right in
(before having a clear understanding of what is needed)
• Things will become clear as we build the software
• Project stakeholders will be able to better understand what they
need only after examining early iterations of the software
• Things change so rapidly that requirements engineering is a waste
of time
• The bottom line is producing a working program and that all else is
secondary
• All of these arguments contain some truth, especially for small projects
that take less than two or three month to complete
• However, as software grows in size and complexity, these arguments
begin to break down and can lead to a failed software project
8
Solution:
Requirements Engineering
9
Requirements Engineering Tasks
• Seven distinct tasks
• Inception
• Elicitation
• Elaboration
• Negotiation
• Specification
• Validation
• Requirements Management
• Some of these tasks may occur in parallel and all are
adapted to the needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and
construction of the software
10
11
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Inception Task
•During inception, the requirements engineer asks a set
of questions to establish…
• A basic understanding of the problem
• The people who want a solution
• The nature of the solution that is desired
• The effectiveness of preliminary communication and
collaboration between the customer and the developer
•Through these questions, the requirements engineer
needs to…
• Identify the stakeholders
• Recognize multiple viewpoints
• Work toward collaboration(give and take policy)
• Initiate the communication
12
The First Set of Questions
•Who is behind the request for this work?
•Who will use the solution?
•What will be the economic benefit of a
successful solution?
•Is there another source for the solution that
you need?
13
These questions focus on the customer, other stakeholders,
the overall goals, and the benefits
The Next Set of Questions
•How would you characterize "good" output that
would be generated by a successful solution?
•What problem(s) will this solution address?
•Can you show me (or describe) the business
environment in which the solution will be used?
14
These questions enable the requirements engineer to gain a
better understanding of the problem and allow the
customer to voice his or her perceptions about a solution
15
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Elicitation Work Products
• A statement of need and feasibility
• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders who
participated in requirements elicitation
• A description of the system's technical environment
• A list of requirements (organized by function) and the
domain constraints that apply to each
• A set of preliminary usage scenarios (in the form of use
cases) that provide insight into the use of the system or
product under different operating conditions
• Any prototypes developed to better define requirements
16
The work products will vary depending on the system, but should
include one or more of the following items
Elicitation Task
• Eliciting requirements is difficult because of
• Problems of scope in identifying the boundaries of the
system or specifying too much technical detail rather than
overall system objectives
• Problems of understanding what is wanted, what the
problem domain is, and what the computing environment can
handle (Information that is believed to be "obvious" is often
omitted)
• Problems of volatility because the requirements change over
time
• Elicitation may be accomplished through two activities
• Collaborative requirements gathering
• Quality function deployment
17
Basic Guidelines of Collaborative
Requirements Gathering
• Meetings are conducted and attended by both software
engineers, customers, and other interested stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all
important points but informal enough to encourage the
free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls
the meeting
• The goal is to identify the problem, propose elements of
the solution, negotiate different approaches, and specify a
preliminary set of solution requirements
18
Quality Function Deployment
• This is a technique that translates the needs of the
customer into technical requirements for software
• It emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the
engineering process through functions, information, and
tasks
• It identifies three types of requirements
• Normal requirements: These requirements are the objectives and
goals stated for a product or system during meetings with the
customer
• Expected requirements: These requirements are implicit to the
product or system and may be so fundamental that the customer
does not explicitly state them
• Exciting requirements: These requirements are for features that go
beyond the customer's expectations and prove to be very satisfying
when present
19
20
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Elaboration Task
• During elaboration, the software engineer takes the
information obtained during inception and elicitation and
begins to expand and refine it
• Elaboration focuses on developing a refined technical
model of software functions, features, and constraints
• It is an analysis modeling task
• Use cases are developed
• Domain classes are identified along with their attributes and
relationships
• State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the
functional, informational, and behavioral model of the
problem
21
Developing Use Cases
• Step One – Define the set of actors that will be involved in
the story
• Actors are people, devices, or other systems that use the system or
product within the context of the function and behavior that is to be
described
• Actors are anything that communicate with the system or product
and that are external to the system itself
• Step Two – Develop use cases, where each one answers a
set of questions
22
(More on next slide)
Questions Commonly Answered by a
Use Case
• Who is the primary actor(s), the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the scenario begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the scenario is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or
change?
• Will the actor have to inform the system about changes in the
external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
23
24
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Negotiation Task
• During negotiation, the software engineer reconciles the
conflicts between what the customer wants and what can
be achieved given limited business resources
• Requirements are ranked (i.e., prioritized) by the
customers, users, and other stakeholders
• Risks associated with each requirement are identified and
analyzed
• Rough guesses of development effort are made and used
to assess the impact of each requirement on project cost
and delivery time
• Using an iterative approach, requirements are eliminated,
combined and/or modified so that each party achieves
some measure of satisfaction
25
26
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Specification Task
• A specification is the final work product produced by the
requirements engineer
• It is normally in the form of a software requirements
specification
• It serves as the foundation for subsequent software
engineering activities
• It describes the function and performance of a computer-
based system and the constraints that will govern its
development
• It formalizes requirements of the proposed software in
both a graphical and textual format
27
Typical Contents of a Software
Requirements Specification
• Requirements
• Software requirements grouped by capabilities (i.e., functions,
objects)
• Software external interface requirements
• Software internal interface requirements
• Software internal data requirements
• Other software requirements (safety, security, privacy,
environment, hardware, software, communications, quality,
personnel, training, logistics, etc.)
• Design and implementation constraints
• Qualification provisions to ensure each requirement has
been met
• Demonstration, test, analysis, inspection, etc.
28
29
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation Task
• During validation, the work products produced as a result
of requirements engineering are assessed for quality
• The specification is examined to ensure that
• all software requirements have been stated unambiguously
• inconsistencies, omissions, and errors have been detected and
corrected
• the work products conform to the standards established for the
process, the project, and the product
• The formal technical review serves as the primary
requirements validation mechanism
• Members include software engineers, customers, users, and other
stakeholders
30
Questions to ask when
Validating Requirements
• Is each requirement consistent with the overall objective
for the system/product?
• Have all requirements been specified at the proper level?
That is, do some requirements provide a level of technical
detail that is inappropriate at this stage?
• Is each requirement unambiguous?
• Does each requirement have attribution? That is, is a
source (generally, a specific individual) noted for each
requirement?
31(more on next slide)
Questions to ask when
Validating Requirements
(continued)
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment
that will house the system or product?
• Is each requirement testable, once implemented?
• Approaches: Demonstration, actual test, analysis, or inspection
• Does the requirements model properly reflect the
information, function, and behavior of the system to be
built?
• Has the requirements model been “partitioned” in a way
that exposes progressively more detailed information about
the system?
32
33
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification
Requirements Management
Task
• During requirements management, the project team
performs a set of activities to identify, control, and track
requirements and changes to the requirements at any time
as the project proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more
traceability tables
• These tables may be stored in a database that relate
features, sources, dependencies, subsystems, and
interfaces to the requirements
• A requirements traceability table is also placed at the end
of the software requirements specification
34
Summary
35
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification


More Related Content

What's hot

What's hot (14)

requirement documentation
requirement documentation requirement documentation
requirement documentation
 
Manual testing interview question by INFOTECH
Manual testing interview question by INFOTECHManual testing interview question by INFOTECH
Manual testing interview question by INFOTECH
 
What is-requirement-traceability-matrix-and-why-is-it-needed-
What is-requirement-traceability-matrix-and-why-is-it-needed-What is-requirement-traceability-matrix-and-why-is-it-needed-
What is-requirement-traceability-matrix-and-why-is-it-needed-
 
E commerce Testing
E commerce TestingE commerce Testing
E commerce Testing
 
Requirements validation - requirements engineering
Requirements validation - requirements engineeringRequirements validation - requirements engineering
Requirements validation - requirements engineering
 
Istqb 4-테스트설계기법-2015-3-배포
Istqb 4-테스트설계기법-2015-3-배포Istqb 4-테스트설계기법-2015-3-배포
Istqb 4-테스트설계기법-2015-3-배포
 
Boolean difference examples
Boolean difference examplesBoolean difference examples
Boolean difference examples
 
Agile Testing and Test Automation
Agile Testing and Test AutomationAgile Testing and Test Automation
Agile Testing and Test Automation
 
Roles and Responsibilities of a BA
Roles and Responsibilities of a BARoles and Responsibilities of a BA
Roles and Responsibilities of a BA
 
DFD Examples.ppt
DFD Examples.pptDFD Examples.ppt
DFD Examples.ppt
 
Change management in Software Engineering
Change management in Software EngineeringChange management in Software Engineering
Change management in Software Engineering
 
Requirements Traceability - The Tie That Binds
Requirements Traceability - The Tie That BindsRequirements Traceability - The Tie That Binds
Requirements Traceability - The Tie That Binds
 
Requirements Validation
Requirements ValidationRequirements Validation
Requirements Validation
 
Software Processes
Software Processes Software Processes
Software Processes
 

Similar to Requirementengg

Requirement engineering in S/W Engineering
Requirement engineering in S/W EngineeringRequirement engineering in S/W Engineering
Requirement engineering in S/W Engineering
Mikel Raj
 
04 fse understandingrequirements
04 fse understandingrequirements04 fse understandingrequirements
04 fse understandingrequirements
Mohesh Chandran
 
Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7
Dhairya Joshi
 

Similar to Requirementengg (20)

SRE.pptx
SRE.pptxSRE.pptx
SRE.pptx
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
Requirements Engineering
Requirements EngineeringRequirements Engineering
Requirements Engineering
 
software requirement
software requirement software requirement
software requirement
 
req engg (1).ppt
req engg (1).pptreq engg (1).ppt
req engg (1).ppt
 
Software engineering
Software engineeringSoftware engineering
Software engineering
 
requirements analysis and design
requirements analysis and designrequirements analysis and design
requirements analysis and design
 
Software Requirements engineering
Software Requirements engineeringSoftware Requirements engineering
Software Requirements engineering
 
Requirement engineering in S/W Engineering
Requirement engineering in S/W EngineeringRequirement engineering in S/W Engineering
Requirement engineering in S/W Engineering
 
Requirements engineering process in software engineering
Requirements engineering process in software engineeringRequirements engineering process in software engineering
Requirements engineering process in software engineering
 
3. 1 req elicitation
3. 1 req elicitation3. 1 req elicitation
3. 1 req elicitation
 
Requirement Engineering.pdf
Requirement Engineering.pdfRequirement Engineering.pdf
Requirement Engineering.pdf
 
04 fse understandingrequirements
04 fse understandingrequirements04 fse understandingrequirements
04 fse understandingrequirements
 
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
2nd MODULE  Software Requirements   _ SW ENGG  22CSE141.pdf2nd MODULE  Software Requirements   _ SW ENGG  22CSE141.pdf
2nd MODULE Software Requirements _ SW ENGG 22CSE141.pdf
 
Requirement Analysis
Requirement AnalysisRequirement Analysis
Requirement Analysis
 
Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7Software engg. pressman_ch-6 & 7
Software engg. pressman_ch-6 & 7
 
Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement Requirement Engineering Processes & Eliciting Requirement
Requirement Engineering Processes & Eliciting Requirement
 
UNIT-II MMB.pptx
UNIT-II MMB.pptxUNIT-II MMB.pptx
UNIT-II MMB.pptx
 
Development Guideline
Development GuidelineDevelopment Guideline
Development Guideline
 
5. SE RequirementEngineering task.ppt
5. SE RequirementEngineering task.ppt5. SE RequirementEngineering task.ppt
5. SE RequirementEngineering task.ppt
 

More from Prof.Dharmishtha R. Chaudhari (7)

Php tutorial
Php tutorialPhp tutorial
Php tutorial
 
Cdma
CdmaCdma
Cdma
 
Searching techniques
Searching techniquesSearching techniques
Searching techniques
 
Searching
SearchingSearching
Searching
 
Srs
SrsSrs
Srs
 
Requirement analysis
Requirement analysisRequirement analysis
Requirement analysis
 
RESUME_2015
RESUME_2015RESUME_2015
RESUME_2015
 

Recently uploaded

Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night StandCall Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
amitlee9823
 
Call Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort Service
Call Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort ServiceCall Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort Service
Call Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort Service
9953056974 Low Rate Call Girls In Saket, Delhi NCR
 
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
dollysharma2066
 
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
dharasingh5698
 
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak HamilCara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Kandungan 087776558899
 
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
dharasingh5698
 
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoorTop Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
dharasingh5698
 

Recently uploaded (20)

chapter 5.pptx: drainage and irrigation engineering
chapter 5.pptx: drainage and irrigation engineeringchapter 5.pptx: drainage and irrigation engineering
chapter 5.pptx: drainage and irrigation engineering
 
Introduction to Serverless with AWS Lambda
Introduction to Serverless with AWS LambdaIntroduction to Serverless with AWS Lambda
Introduction to Serverless with AWS Lambda
 
VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...
VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...
VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...
 
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night StandCall Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
 
Unit 1 - Soil Classification and Compaction.pdf
Unit 1 - Soil Classification and Compaction.pdfUnit 1 - Soil Classification and Compaction.pdf
Unit 1 - Soil Classification and Compaction.pdf
 
Call Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort Service
Call Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort ServiceCall Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort Service
Call Girls in Netaji Nagar, Delhi 💯 Call Us 🔝9953056974 🔝 Escort Service
 
2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects
 
Call Girls Pimpri Chinchwad Call Me 7737669865 Budget Friendly No Advance Boo...
Call Girls Pimpri Chinchwad Call Me 7737669865 Budget Friendly No Advance Boo...Call Girls Pimpri Chinchwad Call Me 7737669865 Budget Friendly No Advance Boo...
Call Girls Pimpri Chinchwad Call Me 7737669865 Budget Friendly No Advance Boo...
 
Employee leave management system project.
Employee leave management system project.Employee leave management system project.
Employee leave management system project.
 
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
 
(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7
(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7
(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7
 
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
 
(INDIRA) Call Girl Aurangabad Call Now 8617697112 Aurangabad Escorts 24x7
(INDIRA) Call Girl Aurangabad Call Now 8617697112 Aurangabad Escorts 24x7(INDIRA) Call Girl Aurangabad Call Now 8617697112 Aurangabad Escorts 24x7
(INDIRA) Call Girl Aurangabad Call Now 8617697112 Aurangabad Escorts 24x7
 
Water Industry Process Automation & Control Monthly - April 2024
Water Industry Process Automation & Control Monthly - April 2024Water Industry Process Automation & Control Monthly - April 2024
Water Industry Process Automation & Control Monthly - April 2024
 
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
 
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak HamilCara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
 
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
 
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoorTop Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
 
Double Revolving field theory-how the rotor develops torque
Double Revolving field theory-how the rotor develops torqueDouble Revolving field theory-how the rotor develops torque
Double Revolving field theory-how the rotor develops torque
 
Unleashing the Power of the SORA AI lastest leap
Unleashing the Power of the SORA AI lastest leapUnleashing the Power of the SORA AI lastest leap
Unleashing the Power of the SORA AI lastest leap
 

Requirementengg

  • 1. Requirements Engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. 2
  • 2. Constraints • Constraints are things that we live with in our daily lives, accept them, and move on. • Constraints are things that affect your product but are “out of your control”. • Careful planning, collaboration with internal and external stakeholders, and holding yourself responsible for what you say and do is the professional way of doing things. • For example Economical Constraints, Managerial Constraints, Technical Constraints, Social Constraints. 3
  • 3. Types of Requirement •User Requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. For E.g. User Interface, Natural language etc. •System Requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. For E.g. Generating Sales Report, Customers data etc. Defines what should be implemented? 4
  • 4. Functional and Non-Functional Requirements • Functional requirements • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. • May state what the system should not do. • Non-functional requirements •Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. • Domain requirements • Constraints on the system from the domain of operation 5
  • 5. Requirements Engineering Requirements engineering tasks: - Inception - Elicitation - Elaboration - Negotiation - Specification - Validation - Requirements Management
  • 6. The Problems with our Requirements Practices •We have trouble understanding the requirements that we do acquire from the customer •We often record requirements in a disorganized manner •We spend far too little time verifying what we do record •Most importantly, we fail to establish a solid foundation for the system or software that the user wants built 7 (more on next slide)
  • 7. The Problems with our Requirements Practices (continued) • Many software developers argue that • Building software is so compelling that we want to jump right in (before having a clear understanding of what is needed) • Things will become clear as we build the software • Project stakeholders will be able to better understand what they need only after examining early iterations of the software • Things change so rapidly that requirements engineering is a waste of time • The bottom line is producing a working program and that all else is secondary • All of these arguments contain some truth, especially for small projects that take less than two or three month to complete • However, as software grows in size and complexity, these arguments begin to break down and can lead to a failed software project 8
  • 9. Requirements Engineering Tasks • Seven distinct tasks • Inception • Elicitation • Elaboration • Negotiation • Specification • Validation • Requirements Management • Some of these tasks may occur in parallel and all are adapted to the needs of the project • All strive to define what the customer wants • All serve to establish a solid foundation for the design and construction of the software 10
  • 11. Inception Task •During inception, the requirements engineer asks a set of questions to establish… • A basic understanding of the problem • The people who want a solution • The nature of the solution that is desired • The effectiveness of preliminary communication and collaboration between the customer and the developer •Through these questions, the requirements engineer needs to… • Identify the stakeholders • Recognize multiple viewpoints • Work toward collaboration(give and take policy) • Initiate the communication 12
  • 12. The First Set of Questions •Who is behind the request for this work? •Who will use the solution? •What will be the economic benefit of a successful solution? •Is there another source for the solution that you need? 13 These questions focus on the customer, other stakeholders, the overall goals, and the benefits
  • 13. The Next Set of Questions •How would you characterize "good" output that would be generated by a successful solution? •What problem(s) will this solution address? •Can you show me (or describe) the business environment in which the solution will be used? 14 These questions enable the requirements engineer to gain a better understanding of the problem and allow the customer to voice his or her perceptions about a solution
  • 15. Elicitation Work Products • A statement of need and feasibility • A bounded statement of scope for the system or product • A list of customers, users, and other stakeholders who participated in requirements elicitation • A description of the system's technical environment • A list of requirements (organized by function) and the domain constraints that apply to each • A set of preliminary usage scenarios (in the form of use cases) that provide insight into the use of the system or product under different operating conditions • Any prototypes developed to better define requirements 16 The work products will vary depending on the system, but should include one or more of the following items
  • 16. Elicitation Task • Eliciting requirements is difficult because of • Problems of scope in identifying the boundaries of the system or specifying too much technical detail rather than overall system objectives • Problems of understanding what is wanted, what the problem domain is, and what the computing environment can handle (Information that is believed to be "obvious" is often omitted) • Problems of volatility because the requirements change over time • Elicitation may be accomplished through two activities • Collaborative requirements gathering • Quality function deployment 17
  • 17. Basic Guidelines of Collaborative Requirements Gathering • Meetings are conducted and attended by both software engineers, customers, and other interested stakeholders • Rules for preparation and participation are established • An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas • A "facilitator" (customer, developer, or outsider) controls the meeting • The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements 18
  • 18. Quality Function Deployment • This is a technique that translates the needs of the customer into technical requirements for software • It emphasizes an understanding of what is valuable to the customer and then deploys these values throughout the engineering process through functions, information, and tasks • It identifies three types of requirements • Normal requirements: These requirements are the objectives and goals stated for a product or system during meetings with the customer • Expected requirements: These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them • Exciting requirements: These requirements are for features that go beyond the customer's expectations and prove to be very satisfying when present 19
  • 20. Elaboration Task • During elaboration, the software engineer takes the information obtained during inception and elicitation and begins to expand and refine it • Elaboration focuses on developing a refined technical model of software functions, features, and constraints • It is an analysis modeling task • Use cases are developed • Domain classes are identified along with their attributes and relationships • State machine diagrams are used to capture the life on an object • The end result is an analysis model that defines the functional, informational, and behavioral model of the problem 21
  • 21. Developing Use Cases • Step One – Define the set of actors that will be involved in the story • Actors are people, devices, or other systems that use the system or product within the context of the function and behavior that is to be described • Actors are anything that communicate with the system or product and that are external to the system itself • Step Two – Develop use cases, where each one answers a set of questions 22 (More on next slide)
  • 22. Questions Commonly Answered by a Use Case • Who is the primary actor(s), the secondary actor(s)? • What are the actor’s goals? • What preconditions should exist before the scenario begins? • What main tasks or functions are performed by the actor? • What exceptions might be considered as the scenario is described? • What variations in the actor’s interaction are possible? • What system information will the actor acquire, produce, or change? • Will the actor have to inform the system about changes in the external environment? • What information does the actor desire from the system? • Does the actor wish to be informed about unexpected changes? 23
  • 24. Negotiation Task • During negotiation, the software engineer reconciles the conflicts between what the customer wants and what can be achieved given limited business resources • Requirements are ranked (i.e., prioritized) by the customers, users, and other stakeholders • Risks associated with each requirement are identified and analyzed • Rough guesses of development effort are made and used to assess the impact of each requirement on project cost and delivery time • Using an iterative approach, requirements are eliminated, combined and/or modified so that each party achieves some measure of satisfaction 25
  • 26. Specification Task • A specification is the final work product produced by the requirements engineer • It is normally in the form of a software requirements specification • It serves as the foundation for subsequent software engineering activities • It describes the function and performance of a computer- based system and the constraints that will govern its development • It formalizes requirements of the proposed software in both a graphical and textual format 27
  • 27. Typical Contents of a Software Requirements Specification • Requirements • Software requirements grouped by capabilities (i.e., functions, objects) • Software external interface requirements • Software internal interface requirements • Software internal data requirements • Other software requirements (safety, security, privacy, environment, hardware, software, communications, quality, personnel, training, logistics, etc.) • Design and implementation constraints • Qualification provisions to ensure each requirement has been met • Demonstration, test, analysis, inspection, etc. 28
  • 29. Validation Task • During validation, the work products produced as a result of requirements engineering are assessed for quality • The specification is examined to ensure that • all software requirements have been stated unambiguously • inconsistencies, omissions, and errors have been detected and corrected • the work products conform to the standards established for the process, the project, and the product • The formal technical review serves as the primary requirements validation mechanism • Members include software engineers, customers, users, and other stakeholders 30
  • 30. Questions to ask when Validating Requirements • Is each requirement consistent with the overall objective for the system/product? • Have all requirements been specified at the proper level? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? • Is each requirement unambiguous? • Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? 31(more on next slide)
  • 31. Questions to ask when Validating Requirements (continued) • Do any requirements conflict with other requirements? • Is each requirement achievable in the technical environment that will house the system or product? • Is each requirement testable, once implemented? • Approaches: Demonstration, actual test, analysis, or inspection • Does the requirements model properly reflect the information, function, and behavior of the system to be built? • Has the requirements model been “partitioned” in a way that exposes progressively more detailed information about the system? 32
  • 33. Requirements Management Task • During requirements management, the project team performs a set of activities to identify, control, and track requirements and changes to the requirements at any time as the project proceeds • Each requirement is assigned a unique identifier • The requirements are then placed into one or more traceability tables • These tables may be stored in a database that relate features, sources, dependencies, subsystems, and interfaces to the requirements • A requirements traceability table is also placed at the end of the software requirements specification 34