Your SlideShare is downloading. ×

Requirements Engineering

6,641

Published on

Objectives: …

Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.

Published in: Technology, Business
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,641
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
537
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. REQUIREMENTS ENGINEERING Developing & Managing Requirements Requirements Engineering 1 Benoy R Nair 27-Aug-2009
  • 2. Objectives To understand the different processes in the realm of ‘Requirements Engineering’. To see the challenges in requirements development and the importance of getting requirements right in an IT project. To understand the different techniques used in different phases and processes of requirements development and management. Requirements Engineering 2 Benoy R Nair 27-Aug-2009
  • 3. REQUIREMENT Requirements Engineering 3 Benoy R Nair 27-Aug-2009
  • 4. What is a ‘Requirement’? Requirements Engineering 4 Benoy R Nair 27-Aug-2009
  • 5. What is a ‘Requirement’? “A condition or capability to which a system must conform.” It can be any one of the following: – A capability needed by a customer or user to solve a problem or achieve an objective. – A capability that must be met or possessed by a system to satisfy a contract, standard, specification, regulation, or other formally imposed document. – A restriction imposed by a stakeholder. Requirements Engineering 5 Benoy R Nair 27-Aug-2009
  • 6. From Needs to Requirements PROBLEM DOMAIN SOLUTION DOMAIN Requirements Engineering 6 Benoy R Nair 27-Aug-2009
  • 7. Requirement Categories (1) Functional Requirements Non Functional Requirements (NFRs) – Performance – Security – Logging – Reliability Requirements Engineering 7 Benoy R Nair 27-Aug-2009
  • 8. Requirement Categories (2) Functional Requirements Technical Requirements Operational Requirements Transitional Requirements Requirements Engineering 8 Benoy R Nair 27-Aug-2009
  • 9. Why do we need requirements? Project scoping Cost estimating Budgeting Project scheduling Software design Software testing Documentation and training manuals Requirements Engineering 9 Benoy R Nair 27-Aug-2009
  • 10. Why is it important to get the requirements right? Requirements Engineering 10 Benoy R Nair 27-Aug-2009
  • 11. Why is it important to get the requirements right? Phase in which fixed Relative Cost Requirements 1 Design 3–6 Coding 10 Development Testing 15 – 40 Acceptance Testing 30 – 70 Operations 40 – 1000 Requirements Engineering 11 Benoy R Nair 27-Aug-2009
  • 12. What are the factors that cause projects to be challenged? Factors Percentage of Responses Lack of User Input 12.8% Incomplete Requirements 12.3% Changing Requirements 11.8% Lack of Executive Support 7.5% Technology Incompetence 7.0% Lack of Resources 6.4% Unrealistic Expectations 5.9% Unclear Objectives 5.3% Unrealistic Time Frames 3.7% Other 23.0% Requirements Engineering 12 Benoy R Nair 27-Aug-2009
  • 13. Why projects are impaired and ultimately cancelled? Factors Percentage of Responses Incomplete Requirements 13.1% Lack of User Involvement 12.4% Lack of Resources 10.6% Unrealistic Expectations 9.9% Lack of Executive Support 9.3% Changing Requirements 8.7% Lack of Planning 8.1% Didn’t need it any longer 7.5% Lack of IT Management 4.3% Technology Illiteracy 9.9% Requirements Engineering 13 Benoy R Nair 27-Aug-2009
  • 14. Characteristics of a Good Requirement Correct Atomic Clear Necessary Understandable Implementation-free Unambiguous Consistent Testable (Verifiable) Complete Feasible Non-redundant Independent Requirements Engineering 14 Benoy R Nair 27-Aug-2009
  • 15. REQUIREMENTS ENGINEERING Requirements Engineering 15 Benoy R Nair 27-Aug-2009
  • 16. Requirements Engineering Requirements Engineering 16 Benoy R Nair 27-Aug-2009
  • 17. Requirements Development Requirements Engineering 17 Benoy R Nair 27-Aug-2009
  • 18. Requirements Development REQUIREMENTS ELICITATION Requirements Engineering 18 Benoy R Nair 27-Aug-2009
  • 19. What is Requirements Elicitation? Requirements Engineering 19 Benoy R Nair 27-Aug-2009
  • 20. What is Requirements Elicitation? The process of discovering the requirements for a system by communication with customers, system users and others who have a stake in the system development. Requirements Engineering 20 Benoy R Nair 27-Aug-2009
  • 21. So how do we elicit requirements? Identify relevant requirements sources. Ask them appropriate questions to understand their needs. Look for implications, inconsistencies, and unresolved issues in gathered information. Confirm your understanding of requirements with the users. Synthesize appropriate statements of the requirements. Requirements Engineering 21 Benoy R Nair 27-Aug-2009
  • 22. Requirements Elicitation Problems Problems of Scope – The requirements may address too little or too much information Problems of Understanding – Wrong/ different understanding of the requirements within and between groups Problems of Volatility – Changing nature of requirements Requirements Engineering 22 Benoy R Nair 27-Aug-2009
  • 23. Problems of Scope 1. The boundary of the system is ill-defined 2. Unnecessary design information may be given Requirements Engineering 23 Benoy R Nair 27-Aug-2009
  • 24. Problems of Understanding Users have incomplete understanding of their needs. Users have poor understanding of computer capabilities and limitations. Analysts have poor knowledge of problem domain. User and analyst speak different languages. Ease of omitting “obvious” information. Conflicting views of different users. Requirements are often vague and un-testable, e.g., “user friendly” and “robust”. Requirements Engineering 24 Benoy R Nair 27-Aug-2009
  • 25. Problems of Volatility Requirements evolve over time Requirements Engineering 25 Benoy R Nair 27-Aug-2009
  • 26. Challenges of Requirements Elicitation “Yes, but…” syndrome – Stems from human nature and the users’ inability to experience the software as they might experience a physical device. The Undiscovered Ruins – The more you find, the more you realize still remain. “User and Developer” syndrome – Reflects the profound difference between the two, making communication difficult. “Living with the sins of your predecessors” syndrome – No trust between the groups based on previous interactions and earlier experiences. Requirements Engineering 26 Benoy R Nair 27-Aug-2009
  • 27. Requirements Elicitation Techniques Questionnaire Interviewing Requirements Workshops Brain storming Use cases Role Playing Prototyping Story boards Requirements Engineering 27 Benoy R Nair 27-Aug-2009
  • 28. Requirements Development REQUIREMENTS ANALYSIS Requirements Engineering 28 Benoy R Nair 27-Aug-2009
  • 29. What is Requirements Analysis? Requirements Engineering 29 Benoy R Nair 27-Aug-2009
  • 30. What is Requirements Analysis? The process of breaking down user requirements into their components and studying these to develop a set of system requirements. The three major goals of this process are: – Achieve agreement among developers and customers. – Provide a basis for design. – Provide a basis for Verification and Validation (V&V) Requirements Engineering 30 Benoy R Nair 27-Aug-2009
  • 31. Process Model Work Flow Diagramming Model Flow Chart Diagramming Customer Event Diagramming Use Case Diagramming Activity Diagrams Decision Trees 31
  • 32. Process Modeling (Sample diagrams) Requirements Engineering 32 Benoy R Nair 27-Aug-2009
  • 33. Process Modeling (Sample diagrams) Requirements Engineering 33 Benoy R Nair 27-Aug-2009
  • 34. Logical Data Model Entity Relationship Diagramming Data Normalization/ De-Normalization 34
  • 35. Requirements Development REQUIREMENTS SPECIFICATION Requirements Engineering 35 Benoy R Nair 27-Aug-2009
  • 36. What is Requirements Specification? Requirements Engineering 36 Benoy R Nair 27-Aug-2009
  • 37. What is Requirements Specification? “Complete description of the behavior of the system to be developed. Requirements document is a reference document. Contract between stakeholders Must be maintained over the life of the project Requirements Engineering 37 Benoy R Nair 27-Aug-2009
  • 38. Software Requirement Specification Objectives Establish agreement between stakeholders Firm foundation for design Reduce development effort Provide a basis for estimating cost and schedule Reduce rework effort and cost of quality Provide a baseline for validation and verification Facilitate transfer Serve as a basis for enhancement Requirements Engineering 38 Benoy R Nair 27-Aug-2009
  • 39. SRS Document Known as ‘Black-box specification’ Concentrates on – ‘What’ needs to be done – Carefully avoids the ‘how to do’ aspects Serves as a contract Requirements Engineering 39 Benoy R Nair 27-Aug-2009
  • 40. Issues SRS writer must address Functionality External Interfaces Performance Attributes Design Constraints Requirements Engineering 40 Benoy R Nair 27-Aug-2009
  • 41. Specification Principles Separate functionality from implementation Develop model of desired behavior of the system Establish the context in which software operates Define the environment in which system operates The following are NOT included in a SRS: – Project Requirements: Cost, delivery schedules, staffing, reporting procedures – Design Solutions – Product Assurance Plan: Quality Assurance plans, Configuration Management procedures, Verification & Validation procedures Requirements Engineering 41 Benoy R Nair 27-Aug-2009
  • 42. Requirements Development REQUIREMENTS VERIFICATION & VALIDATION Requirements Engineering 42 Benoy R Nair 27-Aug-2009
  • 43. What is Requirements Verification & Validation? Requirements Engineering 43 Benoy R Nair 27-Aug-2009
  • 44. What is Requirements Verification? Proving that each requirement has been satisfied Can be done by logical argument, inspection, modeling, simulation, analysis, expert review, test, demonstration Requirements Engineering 44 Benoy R Nair 27-Aug-2009
  • 45. What is Requirements Validation? Ensuring that the set of requirements is correct, complete & consistent. Ensuring that a model can be created that satisfies the requirements. Ensuring that a real-world solution can be built and tested to prove that it satisfies the requirements. Requirements Engineering 45 Benoy R Nair 27-Aug-2009
  • 46. Requirements V & V: Objectives Certify that the requirements document is an acceptable description of the system to be implemented Check requirements document for: – Correctness, completeness and consistency – Conformance to standards – Requirement conflicts – Technical errors – Ambiguous requirements Requirements Engineering 46 Benoy R Nair 27-Aug-2009
  • 47. Requirements: Analysis & Validation Analysis works with raw requirements as elicited from the system stakeholders. – “Have we got the right requirements?” is the key question to be answered at this stage. Validation works with final draft of the requirements document i.e. with negotiated and agreed requirements. – “Have we got the requirements right?” is the key question to be answered at this stage. Requirements Engineering 47 Benoy R Nair 27-Aug-2009
  • 48. Requirements V & V: Inputs & Outputs Requirements Document List of problems Organisational Requirements Knowledge V&V Agreed actions Organisational Standards Requirements Engineering 48 Benoy R Nair 27-Aug-2009
  • 49. Requirements Management Requirements Engineering 49 Benoy R Nair 27-Aug-2009
  • 50. What is Requirements Management? Requirements Engineering 50 Benoy R Nair 27-Aug-2009
  • 51. What is Requirements Management Requirements Engineering 51 Benoy R Nair 27-Aug-2009
  • 52. Requirements Management: Key Activities Understand relationships among key stakeholders and involve them Identify change in requirements Managing & controlling requirements changes Identify and track requirements attributes Trace requirements Requirements Engineering 52 Benoy R Nair 27-Aug-2009
  • 53. Requirements Management Plan A component of Project Management Plan Details the plans and processes for managing requirements through out the entire project life cycle. Requirements Management Plan Requirements Engineering 53 Benoy R Nair 27-Aug-2009
  • 54. Requirement Management Metrics To measure and improve effectiveness of the requirements processes. Typical metrics collected: – Number of Requirement defects – Requirement Review efforts – Changes raised Requirements Engineering 54 Benoy R Nair 27-Aug-2009
  • 55. Requirements Traceability ‘The ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases’ – To ensure the object of the requirements conforms to the requirements by associating each requirement with the object via the traceability matrix. – Concerned with documenting the life of a requirement. – To find the origin of each requirement and track every change which was made to this requirement Requirements Engineering 55 Benoy R Nair 27-Aug-2009
  • 56. Requirements Change Management Process to manage changes in requirements (over the entire project life cycle) Key elements: – Change Process – Change Tracking System Requirements Engineering 56 Benoy R Nair 27-Aug-2009

×