SlideShare a Scribd company logo
Analysis concepts and principles
   Software requirement engineering also called
    requirement analysis bridges the gap
    between system engineering and software
    design.
                  System
                  Engg.
                               S/w req.
                               analysis
                                              S/w design




        Participated by both the customer and developer
Software requirements and analysis--
 Problem recognition
 Evaluation and synthesis
    ◦ focus is on what not how
   Modeling
   Specification
   Review
  Before requirements can be analyzed, modeled or
   specified, they must be gathered through an
   elicitation process.
2. Initiating the process
•   The most commonly used requirement elicitation technique is
    to conduct a meeting/interview.
•   Participants- analyst and the customer.
•   Type of question asked---
    Context free, process questions, meta questions.
2. Facilitated Application Specification
    Technique (FAST) :
• A team oriented approach to requirement

  gathering.
• Encourages creation of a joint team of

  customers and developers who work together
  to identify the problem, propose solution and
  identify a preliminary set of requirements.
Analysis concepts and principles
Basic guidelines for FAST :
•   Meeting is arranged at a neutral site and attended by
    both s/w engineers and customers.
•   Rules for preparation and participation are established.
•   Agenda is set.
•   Appoint a facilitator to control the meeting (can be
    developer, customer or outside expert.)
•   Participants should not criticize and debate.
    Goal should be to identify problems, propose solution
    and identify a preliminary set of requirements
FAST session preparation :
• Initial meetings between customer and

  developer occur where scope is established
  and an overall perception of a solution is
  determined.
• ½ page product request is documented .
• Meeting place, time, date for FAST are

  selected and facilitator is chosen.
• Product request is distributed to all attendees

  before meeting date.
Every FAST attendee is asked to make :
2. List of objects.

3. List of services.

4. List of constraints.
5. List of performance criteria.

Activities of FAST session.
• Each participant presents his/her list of constraints.

• Combined list is prepared eliminating redundant

   entries and adding new ideas.
• List is finalized by the facilitator.
A microprocessor based home security system needs to be built that
would protect against a variety of undesirable situations such as
smoke, fire , illegal entry etc.
The product would use appropriate fire and smoke detectors, window
and door sensors and an alarm that would be set when an untoward
situation occurs and automatically telephone a monitoring agency.
List of objects : Fire detector, smoke detector, window and door
                    sensors, telephone, alarm.
List of services : setting the alarm , monitoring the sensors,
          dialing the phone etc.
List of constraints : Manufacturing cost less than 80 $, must be
                       user friendly, must interface directly to the
             standard phone line.


Performance Criteria : Sensor event should be recognized within 1
  sec.
3. 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.
   Customer satisfaction is of prime importance.
 It identifies three types of requirements
   ◦ Normal requirements: These requirements are the objectives
     and goals stated for a software during meetings with the
     customer.
     Eg : For a Result management system –
     Normal requirement could be-
   • Merit list report
   • Failed student report
   • Calculation of results
◦ Expected requirements: These requirements are
  implicit to the software and are so fundamental that the
  customer does not explicitly state them.
  Eg. Usability, Reliability, ease of installation

◦ Exciting requirements: These requirements are
  features that go beyond the customer's expectations
  and prove to be very satisfying when present.
  Eg :Sophisticated virus protection system
4. Use Case
 It describes the sequence of interactions
  between actors and the system necessary to
  deliver the service that satisfies the goal.
How to create a use case ?
• Identify the different users (actors) of the

  system.
• Create use cases which captures who (actor)

  does what (interaction) without dealing with
  the system internals.
Analysis concepts and principles
Analysis concepts and principles
•    Used to gain a better understanding of the
     problem.
•    Based on constructing a partial implementation of a
     system
•    Prototyping can be :
4.   Throwaway (Closed ended)
•    Here the prototype serves only to demonstrate
     requirements and is discarded after the desired
     knowledge is gained.


•    Since the prototype is ultimately discarded it need
     not be maintainable or use efficient algorithms.
2. Evolutionary (Open ended)
•   Once the prototype has been used and requisite knowledge
    has been gained it is eventually incorporated into the final
    system.
•   Must exhibit all quality attributes of the final product.
Tools used to conduct rapid prototyping :
5.  Fourth generation techniques :
•   4GLs reduce programming effort, the time it takes to
    develop software, and the cost of software development.
Report generators (Oracle repots,QUEST, GEMbase)
Screen generators (Oracle forms etc)
Database Query Languages (SQL, Ingres etc )


•   These tools generate an executable code quickly and hence
    are ideal for rapid prototyping
2. Reusable software components :
• Assemble rather than build the prototype by

  using a set of existing s/w components
3. Formal Specification languages:
• Replace natural language specifcation
• Eg. Set notation , algebraic notation.
• There are tools which convert these formal

  language specifications into executable code.
   The software requirement specification is produced at the
    culmination of the analysis task.
   SRS document is a contract between the development team and the
    customer.
   The SRS document is known as black-box specification since the
    system is considered as a black box whose internal details are not
    known and only its external is visible
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
SRS
   SRS-foundation of the development stage.
   Review is conducted to ensure completeness,
    accuracy and consistency in SRS.
   Avoid vague terms in SRS(usually,often)
   Once review is complete SRS is signed off by
    both customer and developer.

More Related Content

PPT
Software design
ODP
Evolutionary process models se.ppt
PPTX
Software Engineering by Pankaj Jalote
PPT
Software architecture design ppt
PPTX
Software testing
PPTX
Software Cost Estimation Techniques
PPTX
Waterfall model ppt final
PPTX
Functional and non functional
Software design
Evolutionary process models se.ppt
Software Engineering by Pankaj Jalote
Software architecture design ppt
Software testing
Software Cost Estimation Techniques
Waterfall model ppt final
Functional and non functional

What's hot (20)

PDF
SE2018_Lec 18_ Design Principles and Design Patterns
PPT
Software estimation
PPTX
Fundamental design concepts
PPTX
Software development process models
PPTX
Designing Techniques in Software Engineering
PPT
Formal Specification in Software Engineering SE9
PPTX
System testing
PPTX
PPTX
Software Engineering Layered Technology Software Process Framework
PPTX
Estimating Software Maintenance Costs
PPTX
PROTOTYPE MODEL
PPT
Software Configuration Management.ppt
PPTX
Design Concepts in Software Engineering-1.pptx
PPTX
unit testing and debugging
PPTX
Incremental process model
PPTX
Software Engineering Process Models
PPTX
Software myths | Software Engineering Notes
PDF
Software Process Models
PPTX
Software requirements specification
PPTX
COCOMO model
SE2018_Lec 18_ Design Principles and Design Patterns
Software estimation
Fundamental design concepts
Software development process models
Designing Techniques in Software Engineering
Formal Specification in Software Engineering SE9
System testing
Software Engineering Layered Technology Software Process Framework
Estimating Software Maintenance Costs
PROTOTYPE MODEL
Software Configuration Management.ppt
Design Concepts in Software Engineering-1.pptx
unit testing and debugging
Incremental process model
Software Engineering Process Models
Software myths | Software Engineering Notes
Software Process Models
Software requirements specification
COCOMO model
Ad

Viewers also liked (20)

PPT
Analysis modeling
PPT
Analysis modelling
PPT
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
DOCX
Software requirements specification
PPT
Design concepts and principles
PPTX
Modeling and analysis
PPT
Requirements analysis
PDF
Image analysis basics and principles
PPTX
Software analysis and it's principles
PPTX
Beit 381 se lec 15 - 16 - 12 mar27 - req engg 1 of 3
XLS
Cocomo ii estimation
PPTX
SRS(software requirement specification)
PPT
Kano Analysis and Software Requrements
PPTX
Ch9-Software Engineering 9
PPT
Flow oriented modeling
PPTX
Ch7-Software Engineering 9
ODP
Uml
PPT
Lecture 4 software process model (2)
PPT
PPTX
Ch8-Software Engineering 9
Analysis modeling
Analysis modelling
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
Software requirements specification
Design concepts and principles
Modeling and analysis
Requirements analysis
Image analysis basics and principles
Software analysis and it's principles
Beit 381 se lec 15 - 16 - 12 mar27 - req engg 1 of 3
Cocomo ii estimation
SRS(software requirement specification)
Kano Analysis and Software Requrements
Ch9-Software Engineering 9
Flow oriented modeling
Ch7-Software Engineering 9
Uml
Lecture 4 software process model (2)
Ch8-Software Engineering 9
Ad

Similar to Analysis concepts and principles (20)

PPTX
Software Engineering Notes Unit - 1.pptx
PPTX
S.E. Unit 2 software engineering software engineering
PPTX
Requirement Engineering. Types of requirement
PDF
9-Requirements Engineering process, Requirement Elicitation-21-01-2025.pdf
DOC
Softwareenggineering lab manual
PPTX
Project planning and development cycle and testing
PPTX
Software Engineering Unit 2 AKTU Complete
PPTX
Software Development Life Cycle (SDLC )
PPTX
Introduction to Software Engineering Notes.pptx
PPTX
SOFTWARE ENGINEERING FOR BCA DEGREE STUDENTS
PPTX
lec 3rd.pptx
PPSX
Software Development
PPTX
Software Requirements
PPTX
Unit 2 Requirement Elicitation, Analysis, and Specification.pptx
PPTX
Software Engineering- Requirement Elicitation and Specification
PPTX
Requirement Analysis
PPTX
Software engineering Unit 2(Updated)2.pptx
PPTX
Module-2 ppt.pptx contents for software engineering
PPTX
Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx
PDF
CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE ...
Software Engineering Notes Unit - 1.pptx
S.E. Unit 2 software engineering software engineering
Requirement Engineering. Types of requirement
9-Requirements Engineering process, Requirement Elicitation-21-01-2025.pdf
Softwareenggineering lab manual
Project planning and development cycle and testing
Software Engineering Unit 2 AKTU Complete
Software Development Life Cycle (SDLC )
Introduction to Software Engineering Notes.pptx
SOFTWARE ENGINEERING FOR BCA DEGREE STUDENTS
lec 3rd.pptx
Software Development
Software Requirements
Unit 2 Requirement Elicitation, Analysis, and Specification.pptx
Software Engineering- Requirement Elicitation and Specification
Requirement Analysis
Software engineering Unit 2(Updated)2.pptx
Module-2 ppt.pptx contents for software engineering
Advanced Software Engineering Lecture Notes from University of Maiduguri.pptx
CSE2014 SE MODULE - 2 new.pdf CSE2014 SE MODULE - 2 new.pdfCSE2014 SE MODULE ...

More from saurabhshertukde (17)

PPT
Revision sql te it new syllabus
PPT
Oodbms ch 20
PPT
Introduction er & eer
PPT
Introduction er & eer
PPT
Integrity & security
PPT
PPT
Er & eer to relational mapping
PPT
Eer case study
PPT
Chapter 2
PPT
Chapter 1
PPT
Chapter 9
PPT
J2 ee archi
PPT
J2 ee architecture
PPT
Software project-scheduling
PPT
Softwareproject planning
PPT
Pressman ch-3-prescriptive-process-models
PPT
Risk analysis
Revision sql te it new syllabus
Oodbms ch 20
Introduction er & eer
Introduction er & eer
Integrity & security
Er & eer to relational mapping
Eer case study
Chapter 2
Chapter 1
Chapter 9
J2 ee archi
J2 ee architecture
Software project-scheduling
Softwareproject planning
Pressman ch-3-prescriptive-process-models
Risk analysis

Recently uploaded (20)

PDF
Network Security Unit 5.pdf for BCA BBA.
PDF
Modernizing your data center with Dell and AMD
PDF
Spectral efficient network and resource selection model in 5G networks
PDF
Reach Out and Touch Someone: Haptics and Empathic Computing
PDF
cuic standard and advanced reporting.pdf
PDF
Building Integrated photovoltaic BIPV_UPV.pdf
PPTX
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
PPTX
Effective Security Operations Center (SOC) A Modern, Strategic, and Threat-In...
PPT
Teaching material agriculture food technology
PPTX
Cloud computing and distributed systems.
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
PDF
Electronic commerce courselecture one. Pdf
PDF
Shreyas Phanse Resume: Experienced Backend Engineer | Java • Spring Boot • Ka...
PPTX
Big Data Technologies - Introduction.pptx
PDF
NewMind AI Weekly Chronicles - August'25 Week I
PPTX
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
PDF
NewMind AI Monthly Chronicles - July 2025
PDF
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
PDF
The Rise and Fall of 3GPP – Time for a Sabbatical?
Network Security Unit 5.pdf for BCA BBA.
Modernizing your data center with Dell and AMD
Spectral efficient network and resource selection model in 5G networks
Reach Out and Touch Someone: Haptics and Empathic Computing
cuic standard and advanced reporting.pdf
Building Integrated photovoltaic BIPV_UPV.pdf
Detection-First SIEM: Rule Types, Dashboards, and Threat-Informed Strategy
Effective Security Operations Center (SOC) A Modern, Strategic, and Threat-In...
Teaching material agriculture food technology
Cloud computing and distributed systems.
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
Electronic commerce courselecture one. Pdf
Shreyas Phanse Resume: Experienced Backend Engineer | Java • Spring Boot • Ka...
Big Data Technologies - Introduction.pptx
NewMind AI Weekly Chronicles - August'25 Week I
PA Analog/Digital System: The Backbone of Modern Surveillance and Communication
NewMind AI Monthly Chronicles - July 2025
TokAI - TikTok AI Agent : The First AI Application That Analyzes 10,000+ Vira...
The Rise and Fall of 3GPP – Time for a Sabbatical?

Analysis concepts and principles

  • 2. Software requirement engineering also called requirement analysis bridges the gap between system engineering and software design. System Engg. S/w req. analysis S/w design Participated by both the customer and developer
  • 3. Software requirements and analysis--  Problem recognition  Evaluation and synthesis ◦ focus is on what not how  Modeling  Specification  Review
  • 4.  Before requirements can be analyzed, modeled or specified, they must be gathered through an elicitation process. 2. Initiating the process • The most commonly used requirement elicitation technique is to conduct a meeting/interview. • Participants- analyst and the customer. • Type of question asked--- Context free, process questions, meta questions.
  • 5. 2. Facilitated Application Specification Technique (FAST) : • A team oriented approach to requirement gathering. • Encourages creation of a joint team of customers and developers who work together to identify the problem, propose solution and identify a preliminary set of requirements.
  • 7. Basic guidelines for FAST : • Meeting is arranged at a neutral site and attended by both s/w engineers and customers. • Rules for preparation and participation are established. • Agenda is set. • Appoint a facilitator to control the meeting (can be developer, customer or outside expert.) • Participants should not criticize and debate. Goal should be to identify problems, propose solution and identify a preliminary set of requirements
  • 8. FAST session preparation : • Initial meetings between customer and developer occur where scope is established and an overall perception of a solution is determined. • ½ page product request is documented . • Meeting place, time, date for FAST are selected and facilitator is chosen. • Product request is distributed to all attendees before meeting date.
  • 9. Every FAST attendee is asked to make : 2. List of objects. 3. List of services. 4. List of constraints. 5. List of performance criteria. Activities of FAST session. • Each participant presents his/her list of constraints. • Combined list is prepared eliminating redundant entries and adding new ideas. • List is finalized by the facilitator.
  • 10. A microprocessor based home security system needs to be built that would protect against a variety of undesirable situations such as smoke, fire , illegal entry etc. The product would use appropriate fire and smoke detectors, window and door sensors and an alarm that would be set when an untoward situation occurs and automatically telephone a monitoring agency. List of objects : Fire detector, smoke detector, window and door sensors, telephone, alarm. List of services : setting the alarm , monitoring the sensors, dialing the phone etc. List of constraints : Manufacturing cost less than 80 $, must be user friendly, must interface directly to the standard phone line. Performance Criteria : Sensor event should be recognized within 1 sec.
  • 11. 3. 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. Customer satisfaction is of prime importance.  It identifies three types of requirements ◦ Normal requirements: These requirements are the objectives and goals stated for a software during meetings with the customer. Eg : For a Result management system – Normal requirement could be- • Merit list report • Failed student report • Calculation of results
  • 12. ◦ Expected requirements: These requirements are implicit to the software and are so fundamental that the customer does not explicitly state them. Eg. Usability, Reliability, ease of installation ◦ Exciting requirements: These requirements are features that go beyond the customer's expectations and prove to be very satisfying when present. Eg :Sophisticated virus protection system
  • 13. 4. Use Case  It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. How to create a use case ? • Identify the different users (actors) of the system. • Create use cases which captures who (actor) does what (interaction) without dealing with the system internals.
  • 16. Used to gain a better understanding of the problem. • Based on constructing a partial implementation of a system • Prototyping can be : 4. Throwaway (Closed ended) • Here the prototype serves only to demonstrate requirements and is discarded after the desired knowledge is gained. • Since the prototype is ultimately discarded it need not be maintainable or use efficient algorithms.
  • 17. 2. Evolutionary (Open ended) • Once the prototype has been used and requisite knowledge has been gained it is eventually incorporated into the final system. • Must exhibit all quality attributes of the final product. Tools used to conduct rapid prototyping : 5. Fourth generation techniques : • 4GLs reduce programming effort, the time it takes to develop software, and the cost of software development. Report generators (Oracle repots,QUEST, GEMbase) Screen generators (Oracle forms etc) Database Query Languages (SQL, Ingres etc ) • These tools generate an executable code quickly and hence are ideal for rapid prototyping
  • 18. 2. Reusable software components : • Assemble rather than build the prototype by using a set of existing s/w components 3. Formal Specification languages: • Replace natural language specifcation • Eg. Set notation , algebraic notation. • There are tools which convert these formal language specifications into executable code.
  • 19. The software requirement specification is produced at the culmination of the analysis task.  SRS document is a contract between the development team and the customer.  The SRS document is known as black-box specification since the system is considered as a black box whose internal details are not known and only its external is visible
  • 20. SRS
  • 21. SRS
  • 22. SRS
  • 23. SRS
  • 24. SRS
  • 25. SRS
  • 26. SRS
  • 27. SRS
  • 28. SRS
  • 29. SRS
  • 30. SRS-foundation of the development stage.  Review is conducted to ensure completeness, accuracy and consistency in SRS.  Avoid vague terms in SRS(usually,often)  Once review is complete SRS is signed off by both customer and developer.