Requirement Engineering Lec.1 & 2 & 3

  • 1,139 views
Uploaded on

Introduction

Introduction

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,139
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
75
Comments
0
Likes
1

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. SOFTWARE REQUIREMENT ENGINEERINGPrepared By:Ahmed Alageed11- INTRODUCTION
  • 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. COURSE DETAILS 6. Specification of requirements 7. Requirements Analysis 8.Tracking of Requirements 9. Quality Assurance 10. Tools3
  • 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. 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. 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. 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. COURSE REFERENCES4. The Requirements Engineering Handbookby Ralph R. Young5. Software requirements: Styles andtechniques by Soren Lauesen8
  • 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. 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. 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. 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. 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. 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. 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. FUNCTIONAL PRODUCT REQUIREMENTS from the developers point of view:architecture, power supply, load distribution16
  • 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. TYPES OF REQUIREMENTS customer requirements solution/system requirements, product/component requirements18
  • 19. 19
  • 20. PROBLEMS WITH REQUIREMENTS unclear objectives communication problems language barriers knowledge barriers vague formulation too formal formulations ambiguous, overlyspecified, unclear, impossible, contradictoryrequirements20
  • 21. PROBLEMS WITH REQUIREMENTS instability of the requirements bad quality of the requirements insufficient user involvement overlooked user classes inaccurate planning minimal specification21
  • 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. 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. 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. QUALITY CRITERIA FOR REQUIREMENTS The requirements specification must becomplete, consistent, modifiable andtraceable25
  • 26. SOLUTION A solution is the implementation of therequirement Engineering & Requirementmanagement.26
  • 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. CRITICALITY OF REQUIREMENTS Evaluation of the risk of a requirement byevaluating the damage in case of non-fulfillment of a requirement28
  • 29. VALIDATION Process of confirmation that the specificationof a phase or the entire system fulfills thecustomers requirements29
  • 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. DELINEATION BETWEEN REQUIREMENTSMANAGEMENT AND ENGINEERING Requirements Management (RM) includesprocesses for the identification andmanagement of requirements Requirements engineering includes the basicengineering skills31
  • 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. 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.  IEEE 1362: Guide for Information Technology – SystemDefinition34STANDARDS AND NORMS
  • 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. 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. 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