Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Requirement Engineering                            Saranya.V                              AP/CSE,   Sri Vidya College of E...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
Requirement Engineering ProcessHelps software engineer to better understandthe problem.Participants involved:  Software En...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.1 IntroductionRange from High level abstract statement fromDetailed Mathematical Specifications.
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.2 UnderstandingRequirementsCollecting needs from the customer.Managing the Process.Tasks involved:   Inception   Eli...
Inception (Beginning)During         inception,     therequirements asks a set ofquestions to establish:    Basic understan...
Elicitation: (Extraction)Eliciting requirements is difficult because of Problems of scope  identify the boundaries of   ...
Elaboration (explanation)Takes the information obtainedduring inception and elicitation.Focuses on developing a refinedmod...
Negotiation (Cooperation)   Software        engineer    reconciles the conflicts    between      what    the    customer ...
Specifications   Final work product produced by    the requirements engineer.   Form of SRS.   Serves as a foundation....
Validation   Specification is examined to    ensure that all the sw    requirements     have   been    stated unambiguous...
Requirements Management   Project team performs a set of activities to identify,    control and track requirements and ch...
Types of RequirementsCustomer Requirements  Define the expectations in terms of Mission  Objectives, Environment, Constrai...
   Non functional Requirements:   Specify criteria that can be used to judge    the operation of a system rather than   ...
Design Requirements:   Build to, Code to, buy to.     Those who are involving in                                   requir...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.3 Requirement  EngineeringFeasibility Study  Find out the current user needs.  BudgetRequirement Analysis  What the st...
Requirements Document:  Official Statement  Include both a definition and specification  Specify external system behavior ...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.4 Ground WorkEstablishment Ground Work for Requirement Analysis consist of     Identifying stakeholders,     Recogni...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.4.1 Stakeholders       Identification Stakeholder may be a project team member, employee of the user organization or a...
Stakeholder influence and Role in  the projectBe activeInvolvementVested interest.Stakeholder Categories:  Project Manager...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.4.2 Multiple Viewpoint  RecognitionMarketing Group is interested in functionsand features (easy to sell)Support      e...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.4.3 CollaborationEach stakeholders hasdifferent      opinionabout the set ofrequirements.Requirement engineermust iden...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.1.4 Requirement    ElicitationDiscovering the requirement for the system.Identify the requirements by communicating wi...
1.1 Requirement Engineering  1.1.1 Introduction  1.1.2 Understanding Requirements  1.1.3 Requirements Engineering  1.1.4 G...
1.1.4.5 Building Use  CasesUse cases describe the interactionsbetween a user and a system.Focusing on What the system DOES...
Activities involved in use  casesFind actors  Project Manager  Architect  End-users  Customers  Development TeamFind use c...
Steps for developing use case       diagram1.    Use abstract idea2.    Define use case actors3.    Define use case actor ...
Sample Use case Diagram
1.1.4.6 Negotiating Requirements  (RN)Effective practices:  Get the right stakeholder  Establish team work mentality  Plan...
1.1.4.7 Validating RequirementsRequirement ReviewsPrototyping (Model)Model ValidationAcceptance Tests
Upcoming SlideShare
Loading in …5
×

Requirement Engineering

24,607 views

Published on

Published in: Education
  • Be the first to comment

Requirement Engineering

  1. 1. Requirement Engineering Saranya.V AP/CSE, Sri Vidya College of Engineering & Technology, Virudhunagar
  2. 2. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  3. 3. Requirement Engineering ProcessHelps software engineer to better understandthe problem.Participants involved: Software Engineers Managers Customers Users
  4. 4. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  5. 5. 1.1.1 IntroductionRange from High level abstract statement fromDetailed Mathematical Specifications.
  6. 6. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  7. 7. 1.1.2 UnderstandingRequirementsCollecting needs from the customer.Managing the Process.Tasks involved: Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management
  8. 8. Inception (Beginning)During inception, therequirements asks a set ofquestions to establish: Basic understanding of the problem. Nature of the solution that is desired.Requirements Engineersneeds to Identify thestakeholders, recognizemultiple viewpoints, worktoward collaboration andinitiate the communication.
  9. 9. Elicitation: (Extraction)Eliciting requirements is difficult because of Problems of scope  identify the boundaries of the system. Problems of understanding  domain , computing environment. Problems of Volatility  requirements may change over time.Elicitation may be accomplished through two activities:  Collaborative Requirements Gathering  Quality Function Deployment.
  10. 10. Elaboration (explanation)Takes the information obtainedduring inception and elicitation.Focuses on developing a refinedmodel of software functions,features & Constraints.This is an analyzing phase.It defines the functional,informational and behavioralconstraints of the problemdomain.
  11. 11. Negotiation (Cooperation) Software engineer reconciles the conflicts between what the customer wants and what can be achieved. Requirements are ranked by the customer, users and other stakeholders. Risks associated with each requirement are identified.
  12. 12. Specifications Final work product produced by the requirements engineer. Form of SRS. Serves as a foundation. It formalizes the functional and behavioral requirements of the proposed software in both the graphical and textual format.
  13. 13. Validation Specification is examined to ensure that all the sw requirements have been stated unambiguously. Errors have been detected and corrected. Members involved:  Software Engineers  Customers  Users  Other stakeholders.
  14. 14. Requirements Management Project team performs a set of activities to identify, control and track requirements and changes to the requirements at any times as the project proceeds. Each requirement is assigned a unique identifier. Place the requirements into one or traceability tables. Tables may be stored in a database that relate features, sources, dependencies subsystems and interfaces to the requirements.
  15. 15. Types of RequirementsCustomer Requirements Define the expectations in terms of Mission Objectives, Environment, Constraints and Measures of Effectiveness and Suitability. (MOE/MOS)Functional Requirements Explain what has to be done. Identify the necessary action or activity and task. Used as the top level functions for functional analysis.
  16. 16.  Non functional Requirements: Specify criteria that can be used to judge the operation of a system rather than behaviors. Performance Requirements: Examine which a mission or function must be executed. Measured in terms of quality, quantity, timeliness or readiness.
  17. 17. Design Requirements: Build to, Code to, buy to. Those who are involving in requirement Analysis: Use technical data Requirement Engineer packages and technical System Analyst manuals. System EngineerDerived Requirements: Project Leader Implied or transformed System Engineer from higher level requirement.Allocated Requirement: Higher level : 100 Lower level : 70 and 30
  18. 18. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  19. 19. 1.1.3 Requirement EngineeringFeasibility Study Find out the current user needs. BudgetRequirement Analysis What the stakeholders require from the system.Requirements Definition Define the requirements in a form understandable to the customer.Requirements Specification Define the requirements in detail.
  20. 20. Requirements Document: Official Statement Include both a definition and specification Specify external system behavior Specify implementation constraints. Easy to changeProblems of Requirements Analysis Stakeholders don’t know what they really want Stakeholders express requirements in their own terms Requirement change during the analysis process.
  21. 21. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  22. 22. 1.1.4 Ground WorkEstablishment Ground Work for Requirement Analysis consist of  Identifying stakeholders,  Recognizing viewpoints,  Establishing collaboration among the stakeholders through conducting conversions and questionnaire among the stakeholders.
  23. 23. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  24. 24. 1.1.4.1 Stakeholders Identification Stakeholder may be a project team member, employee of the user organization or a Senior Manager. Stakeholder analysis is a technique to identify and analysis the stakeholders project. Provides information on stakeholders and their relationships, interests and their expectations.Stakeholder expectations and Interests: “Guess Work” Approaches: Using checklist Plotting people in small models.
  25. 25. Stakeholder influence and Role in the projectBe activeInvolvementVested interest.Stakeholder Categories: Project Manager Team Members Team Leads Project Resource Manager Senior Managers, Executives or Sponsors
  26. 26. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  27. 27. 1.1.4.2 Multiple Viewpoint RecognitionMarketing Group is interested in functionsand features (easy to sell)Support engineers may focus onmaintainability of the software.Business managers are interested in afeature that will be ready to meet definedmarket windows.
  28. 28. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  29. 29. 1.1.4.3 CollaborationEach stakeholders hasdifferent opinionabout the set ofrequirements.Requirement engineermust identify areas ofcommonality.Identify the area ofinconsistency.Reduce dependenciesamong engineers.
  30. 30. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  31. 31. 1.1.1.4 Requirement ElicitationDiscovering the requirement for the system.Identify the requirements by communicating with the customers, systemusers and other.Requirements sources: Domain Knowledge Stakeholders Operational Environment Organizational Environment.Elicitation Techniques: Interviews Scenarios Facilitated Meeting Prototypes Observation
  32. 32. 1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment  1.1.4.1 Stakeholders Identification  1.1.4.2 Multiple Viewpoints Recognition  1.1.4.3 Collaboration  1.1.4.4 Requirements Elicitation  1.1.4.5 Building Use Cases  1.1.4.6 Negotiating Requirements  1.1.4.7 Validating Requirements
  33. 33. 1.1.4.5 Building Use CasesUse cases describe the interactionsbetween a user and a system.Focusing on What the system DOES for theuser.Describe the totality of the system andbehavior of the system.Includes: Actors List Use case packages Use case diagrams Use case text
  34. 34. Activities involved in use casesFind actors Project Manager Architect End-users Customers Development TeamFind use casesDescribe the use case.
  35. 35. Steps for developing use case diagram1. Use abstract idea2. Define use case actors3. Define use case actor goals4. Identify reuse opportunity for use case5. Create use case index6. Identify the key components7. Name and briefly describe the use case.8. Create use case basic view9. Create use case alternate flows10. Produce the use case document11. Generate a use case model diagram.
  36. 36. Sample Use case Diagram
  37. 37. 1.1.4.6 Negotiating Requirements (RN)Effective practices: Get the right stakeholder Establish team work mentality Plan team iteration Use Group Support System(GSS) Establish shared vocabulary Maintain list of requirements Record requirement attributes Manage by probabilities Select base decisions Select operational approach Plan more Re-plan before every release Find workable solution Provide training in the negotiation process Use trained facilitator Consider requirement, architecture and market place. Leverage the triple constraint (Cost Vs Time Vs Scope)
  38. 38. 1.1.4.7 Validating RequirementsRequirement ReviewsPrototyping (Model)Model ValidationAcceptance Tests

×