Requirement Engineering

7,359 views
7,065 views

Published on

Published in: Education
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,359
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
370
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

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

×