SOFTWARE REQUIREMENT ENGINEERINGPrepared By:Ahmed Alageed11- INTRODUCTION
COURSE DETAILSThis Course will cover the following Topics: 1. Basics 2. Procedure and Processes 3. Project and Risk Man...
COURSE DETAILS 6. Specification of requirements 7. Requirements Analysis 8.Tracking of Requirements 9. Quality Assuran...
ASSESSMENT METHODThe assessment method will be as following: Final Exam: 60% Mid-Term Exam:15% ( it will be between the5...
COURSE LAB. In the practical part of this course you will berequested to do some tutorial on requirementas well as learni...
CONTACT INFO. You can contact me at any time by Email:Aalageed@neelain.edu.sd I will be available at my office on Sat. a...
COURSE REFERENCES Main Reading:1. Software Engineering by Ian Sommerville,8th edition, Addison-Wesley, 2006.2. Software E...
COURSE REFERENCES4. The Requirements Engineering Handbookby Ralph R. Young5. Software requirements: Styles andtechniques b...
LEARNING TARGET What is a requirement? What is the meaning and purpose ofrequirements? How can requirements be classifi...
LEARNING TARGET What concepts are important in connectionwith requirements? What is the difference between RM(Requiremen...
1. WHAT IS A REQUIREMENT? A requirement is a condition or a skill that auser needs in order to solve a problem orarrive a...
WHAT IS THE MEANING AND PURPOSE OFREQUIREMENTS? Foundation forassessment, planning, execution andmonitoring of the projec...
CLASSIFICATION OF REQUIREMENTS Requirements consist of: process requirements product requirements Process requirements...
PRODUCT REQUIREMENTS Product requirements consist of functionaland non-functional product requirements. Both can be rega...
FUNCTIONAL PRODUCT REQUIREMENTS Functional requirements describe thefunction of the system from the users point of view:...
FUNCTIONAL PRODUCT REQUIREMENTS from the developers point of view:architecture, power supply, load distribution16
NON-FUNCTIONAL PRODUCT REQUIREMENTS Non-functional requirements describe thequality attributes of the system. from the p...
TYPES OF REQUIREMENTS customer requirements solution/system requirements, product/component requirements18
19
PROBLEMS WITH REQUIREMENTS unclear objectives communication problems language barriers knowledge barriers vague formu...
PROBLEMS WITH REQUIREMENTS instability of the requirements bad quality of the requirements insufficient user involvemen...
QUALITY CRITERIA FOR REQUIREMENTS Necessary: If the system can meet prioritized real needswithout the requirement, it isn...
QUALITY CRITERIA FOR REQUIREMENTS Consistent: It is not in conflict with other requirements. Verifiable: Implementation ...
QUALITY CRITERIA FOR REQUIREMENTS Non-redundant: It is not a duplicate requirement. Written using the standard construct...
QUALITY CRITERIA FOR REQUIREMENTS The requirements specification must becomplete, consistent, modifiable andtraceable25
SOLUTION A solution is the implementation of therequirement Engineering & Requirementmanagement.26
PRIORITY OF REQUIREMENTS Commitment Commitment is the degree of obligation Observing legal responsibilities, especially...
CRITICALITY OF REQUIREMENTS Evaluation of the risk of a requirement byevaluating the damage in case of non-fulfillment of...
VALIDATION Process of confirmation that the specificationof a phase or the entire system fulfills thecustomers requiremen...
VERIFICATION Comparison of an intermediate product withits specifications. It is thereby determined ifthe software was de...
DELINEATION BETWEEN REQUIREMENTSMANAGEMENT AND ENGINEERING Requirements Management (RM) includesprocesses for the identif...
STANDARDS AND NORMS ISO 9000: Requirements of a quality management system: defined concepts and basics of a QMS domain...
STANDARDS AND NORMS IEEE 610: Standard Glossary of Software EngineeringTerminology IEEE 830: Recommended Practice for ...
 IEEE 1362: Guide for Information Technology – SystemDefinition34STANDARDS AND NORMS
PROCESS NORMS ISO 12207: Standard for Software Life Cycle Process ISO 15288: System Life Cycle Process ISO 15504: So...
REASONS WHY REQUIREMENT ENGINEERING ISOFTEN NEGLECTED Neglect due to high time pressure Neglect due to an exclusive orie...
POSSIBLE CONSEQUENCES OF NEGLECTINGREQUIREMENTS ENGINEERING Requirements become imprecise Requirements are ambiguous Re...
Upcoming SlideShare
Loading in...5
×

Requirement Engineering Lec.1 & 2 & 3

1,861

Published on

Introduction

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,861
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
124
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Requirement Engineering Lec.1 & 2 & 3

  1. 1. SOFTWARE REQUIREMENT ENGINEERINGPrepared By:Ahmed Alageed11- INTRODUCTION
  2. 2. COURSE DETAILSThis Course will cover the following Topics: 1. Basics 2. Procedure and Processes 3. Project and Risk Management 4. Responsibilities and Roles 5.Identification of Requirements2
  3. 3. COURSE DETAILS 6. Specification of requirements 7. Requirements Analysis 8.Tracking of Requirements 9. Quality Assurance 10. Tools3
  4. 4. ASSESSMENT METHODThe assessment method will be as following: Final Exam: 60% Mid-Term Exam:15% ( it will be between the5th & 10th lecture without any morenotifications) Tutorial & Presentation:25% ( including TheLab. Remarks & attendance.4
  5. 5. COURSE LAB. In the practical part of this course you will berequested to do some tutorial on requirementas well as learning in details some of toolsand model which used in the requirementengineering5
  6. 6. CONTACT INFO. You can contact me at any time by Email:Aalageed@neelain.edu.sd I will be available at my office on Sat. after 12PM6
  7. 7. COURSE REFERENCES Main Reading:1. Software Engineering by Ian Sommerville,8th edition, Addison-Wesley, 2006.2. Software Engineering: A practitionersapproach by Roger S. Pressman, 6th edition,McGraw-Hill International edition, 2005.3. Software Requirements, by Karl E.Wiegers , Microsoft Press © 20037
  8. 8. COURSE REFERENCES4. The Requirements Engineering Handbookby Ralph R. Young5. Software requirements: Styles andtechniques by Soren Lauesen8
  9. 9. LEARNING TARGET What is a requirement? What is the meaning and purpose ofrequirements? How can requirements be classified? What types of requirements are there? What problems are there concerningrequirements?9
  10. 10. LEARNING TARGET What concepts are important in connectionwith requirements? What is the difference between RM(Requirements Management) and RE Requirements Engineering)? What important norms and standards exist? Why is Requirements Engineeringimportant?10
  11. 11. 1. WHAT IS A REQUIREMENT? A requirement is a condition or a skill that auser needs in order to solve a problem orarrive at a goal. A condition or capability that must be met orpossessed by a system or systemcomponent to satisfy acontract, standard, specification, or otherformally imposed document11
  12. 12. WHAT IS THE MEANING AND PURPOSE OFREQUIREMENTS? Foundation forassessment, planning, execution andmonitoring of the project activity Customer expectations Component of agreements, orders, projectplans… Setting of system boundaries, scope ofdelivery, contractual services12
  13. 13. CLASSIFICATION OF REQUIREMENTS Requirements consist of: process requirements product requirements Process requirements:costs, marketing, processing time, sales anddistribution, organization, documentation Describe needs and limitations of thebusiness processes.13
  14. 14. PRODUCT REQUIREMENTS Product requirements consist of functionaland non-functional product requirements. Both can be regarded from the point of viewof the user (external) or customer and from the point of view of the developer(internal).14
  15. 15. FUNCTIONAL PRODUCT REQUIREMENTS Functional requirements describe thefunction of the system from the users point of view: userinterface, applications, services from the customer’s point of view: userinterface, applications, servicesNote: User and customer can be different!15
  16. 16. FUNCTIONAL PRODUCT REQUIREMENTS from the developers point of view:architecture, power supply, load distribution16
  17. 17. NON-FUNCTIONAL PRODUCT REQUIREMENTS Non-functional requirements describe thequality attributes of the system. from the point of view of the user:reliability, performance, usability from the point of view of the customer:reliability, performance, usability from the point of view of the developer:testability, serviceability, tools17
  18. 18. TYPES OF REQUIREMENTS customer requirements solution/system requirements, product/component requirements18
  19. 19. 19
  20. 20. PROBLEMS WITH REQUIREMENTS unclear objectives communication problems language barriers knowledge barriers vague formulation too formal formulations ambiguous, overlyspecified, unclear, impossible, contradictoryrequirements20
  21. 21. PROBLEMS WITH REQUIREMENTS instability of the requirements bad quality of the requirements insufficient user involvement overlooked user classes inaccurate planning minimal specification21
  22. 22. QUALITY CRITERIA FOR REQUIREMENTS Necessary: If the system can meet prioritized real needswithout the requirement, it isn’t necessary. Feasible: The requirement is doable and can be accomplishedwithin budget and schedule. Correct: The facts related to the requirement are accurate, andit is technically and legally possible. Concise: The requirement is stated simply. Unambiguous: The requirement can be interpreted in only oneway. Complete: All conditions under which the requirement appliesare stated, and it expresses a whole idea or statement.22
  23. 23. QUALITY CRITERIA FOR REQUIREMENTS Consistent: It is not in conflict with other requirements. Verifiable: Implementation of the requirement in the systemcan be proved. Traceable: The source of the requirement can be traced, and itcan be tracked throughout the system (e.g., to the design, code,test, and documentation). Allocated: The requirement is assigned to a component of thedesigned system. Design independent: It does not pose a specificimplementation solution.23
  24. 24. QUALITY CRITERIA FOR REQUIREMENTS Non-redundant: It is not a duplicate requirement. Written using the standard construct: The requirement isstated as an imperative using “shall.” Assigned a unique identifier: Each requirement shall have aunique identifying number. Devoid of escape clauses: Language should not include suchphrases as “if,” “when,” “but,” “except,” “unless,” and“although.” Language should not be speculative or general(i.e., avoid wording such as “usually,” “generally,” “often,”“normally,” and “typically”).24
  25. 25. QUALITY CRITERIA FOR REQUIREMENTS The requirements specification must becomplete, consistent, modifiable andtraceable25
  26. 26. SOLUTION A solution is the implementation of therequirement Engineering & Requirementmanagement.26
  27. 27. PRIORITY OF REQUIREMENTS Commitment Commitment is the degree of obligation Observing legal responsibilities, especially incase of faultFault Deviation of the current state from the targetstate Evaluation of the importance/urgency27
  28. 28. CRITICALITY OF REQUIREMENTS Evaluation of the risk of a requirement byevaluating the damage in case of non-fulfillment of a requirement28
  29. 29. VALIDATION Process of confirmation that the specificationof a phase or the entire system fulfills thecustomers requirements29
  30. 30. VERIFICATION Comparison of an intermediate product withits specifications. It is thereby determined ifthe software was developed correctly and ifthe specifications that were determinedduring the previous phase were fulfilled30
  31. 31. DELINEATION BETWEEN REQUIREMENTSMANAGEMENT AND ENGINEERING Requirements Management (RM) includesprocesses for the identification andmanagement of requirements Requirements engineering includes the basicengineering skills31
  32. 32. STANDARDS AND NORMS ISO 9000: Requirements of a quality management system: defined concepts and basics of a QMS domain or industry neutral ISO 9126: Defines a quality model with six categories: Functionality, reliability, usability, efficiency,maintainability, portability32
  33. 33. STANDARDS AND NORMS IEEE 610: Standard Glossary of Software EngineeringTerminology IEEE 830: Recommended Practice for SoftwareRequirements Specifications IEEE 1233: Guide for Developing of System RequirementsSpecifications33
  34. 34.  IEEE 1362: Guide for Information Technology – SystemDefinition34STANDARDS AND NORMS
  35. 35. PROCESS NORMS ISO 12207: Standard for Software Life Cycle Process ISO 15288: System Life Cycle Process ISO 15504: Software Process Improvement and CapabilityDetermination (SPICE) Capability Maturity Model Integrated (CMMI)35
  36. 36. REASONS WHY REQUIREMENT ENGINEERING ISOFTEN NEGLECTED Neglect due to high time pressure Neglect due to an exclusive orientationtoward fast results Neglect due to an exclusive fixation on costs Neglect due to misinterpretations (manythings are seen as given)36
  37. 37. POSSIBLE CONSEQUENCES OF NEGLECTINGREQUIREMENTS ENGINEERING Requirements become imprecise Requirements are ambiguous Requirements are contradictory Requirements that change Requirements that do not fulfill the criteria Requirements that can be interpreteddifferently Missing requirements37
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×