Your SlideShare is downloading. ×
0
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Sw Requirements Engineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sw Requirements Engineering

2,904

Published on

Published in: Economy & Finance, Technology
1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,904
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
8
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 SW
  • 2. Requirements Engineering <ul><li>Definitions, Requirements Engineering Process </li></ul><ul><li>Requirements Document </li></ul><ul><ul><li>for customers/developers </li></ul></ul><ul><li>IEEE Recommended Practice for Software Requirements Overview Std. 830 </li></ul><ul><ul><li>SRS Software Requirements Specifications </li></ul></ul><ul><li>Functional Specification Document </li></ul><ul><ul><li>for developers </li></ul></ul>
  • 3. Definition Q&A
  • 4. Definition <ul><li>Requirements Engineering </li></ul><ul><ul><li>Finding out </li></ul></ul><ul><ul><li>Checking </li></ul></ul><ul><ul><li>Documenting </li></ul></ul>the services and constraints of a software application
  • 5. Requirements Engineering Process Requirements analysis Feasibility report Requirements validation Requirements document Feasibility study Requirements specification System models user and system requirements realism consistency completeness new software product/service
  • 6. Requirements Analysis Requirements sorting Application context understanding Requirements prioritization Requirements collection Requirements grouping Requirements Document
  • 7. Attributes Q&A
  • 8. Attributes <ul><li>Maintainability </li></ul><ul><ul><li>May evolve for changing user requirements </li></ul></ul><ul><li>Dependability </li></ul><ul><ul><li>Reusable, secure, safe </li></ul></ul><ul><li>Efficiency </li></ul><ul><ul><li>Use of resources (CPU, memory) </li></ul></ul><ul><li>Usability </li></ul><ul><ul><li>Used by a group of users (UI) </li></ul></ul><ul><li>Adaptability </li></ul><ul><ul><li>Portability - configurations, OS </li></ul></ul>
  • 9. Requirements Document <ul><li>1. Introduction </li></ul><ul><ul><li>- need for the software program, context, brief functionality . </li></ul></ul><ul><li>2. Hardware </li></ul><ul><ul><li>-special hardware, minimal, optimal configurations. </li></ul></ul><ul><li>3. Conceptual model </li></ul><ul><ul><li>- high level view of the software program </li></ul></ul><ul><li>4. Functional Requirements </li></ul><ul><ul><li>-services provided to the user </li></ul></ul><ul><li>5. Database Requirements </li></ul><ul><ul><li>-logical organization of the data </li></ul></ul><ul><li>6. NonFunctional Requirements </li></ul><ul><ul><li>-other functionality that the software program should have (speed, size, ease of use, reliability,robustness, portability) </li></ul></ul><ul><li>7. Maintenance/evolution </li></ul><ul><ul><li>-anticipated changes due to hardware evolution, changing user needs </li></ul></ul><ul><li>8. Glossary </li></ul><ul><ul><li>-technical terms used </li></ul></ul><ul><li>9. Index </li></ul>
  • 10. Writing style <ul><li>Describe one external behavior (functionality) of the software application. </li></ul><ul><li>Active rather than passive tenses. </li></ul><ul><li>Short sentences. </li></ul><ul><li>Reference number and description </li></ul><ul><li>Itemized facts wherever possible </li></ul><ul><li>Diagrams for complex descriptions </li></ul><ul><li>Precise and well defined terms </li></ul><ul><li>Short paragraphs </li></ul><ul><li>Headings and Sub-headings </li></ul><ul><li>Grammatically correct constructs and spell check </li></ul>
  • 11. SRS Software Requirements Specifications <ul><li>IEEE Std. 830 Recommended Practice for Software Requirements Specifications </li></ul><ul><li>SRS: </li></ul><ul><ul><li>Avoid placing design or project requirements. </li></ul></ul><ul><ul><li>Avoid describing design or implementation details. </li></ul></ul><ul><ul><li>Address the software product not the process of software development. </li></ul></ul><ul><li>Multiple SRSs: separate interface specs docs for interfaces among packages (communication interfaces, sw interfaces, db interfaces) </li></ul>
  • 12. SRS References
  • 13. IEEE Std. 830 SRS Characteristics <ul><li>Correct - all requirements will be met by the software product. </li></ul><ul><li>Unambiguous - every requirements stated has one implementation. </li></ul><ul><li>Complete - it includes: </li></ul><ul><ul><li>All significant requirements: Functional; performance; design constraints; attributes; external interfaces. </li></ul></ul><ul><ul><li>Responses to all classes of input data </li></ul></ul><ul><ul><li>Full labels, references to all figures/tables; glossary . </li></ul></ul><ul><li>Consistent - internally consistent. </li></ul><ul><li>Ranked for importance/stability - identifier for every particular requirement. </li></ul><ul><li>Verifiable - finite cost-effective process to check a particular requirement. </li></ul><ul><li>Modifiable - changes made easily, completely and consistently while retaining the structure and state. </li></ul><ul><li>Traceable - requirements are clear. </li></ul>
  • 14. Prototype SRS Outline <ul><li>Table of Contents </li></ul><ul><li>1. Introduction </li></ul><ul><ul><li>Purpose - purpose and audience for SRS. </li></ul></ul><ul><ul><li>Scope - for the sw: name, usage, benefits, goals . </li></ul></ul><ul><ul><li>Definitions and abbreviations </li></ul></ul><ul><ul><li>References </li></ul></ul><ul><ul><li>Overview </li></ul></ul><ul><li>2. Overall Description </li></ul><ul><ul><li>Product Perspective </li></ul></ul><ul><ul><li>Product Features </li></ul></ul><ul><ul><li>User Characteristics </li></ul></ul><ul><ul><li>Constraints </li></ul></ul><ul><ul><li>Assumptions and dependencies </li></ul></ul>
  • 15. Prototype SRS Outline <ul><li>3. Specific Requirements </li></ul><ul><ul><li>3.1 Functional Requirements </li></ul></ul><ul><ul><ul><li>processing and outputs of the software for certain inputs, specifications provided for validating inputs; sequencing outputs, error response. </li></ul></ul></ul><ul><ul><ul><li>3.1.1 Functional Requirement 1 </li></ul></ul></ul><ul><ul><ul><ul><li>3.1.1.1 Introduction </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.1.1.2 Inputs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.1.1.3 Processing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.1.1.4 Outputs </li></ul></ul></ul></ul><ul><ul><ul><li>3.1.2 Functional Requirement 2 </li></ul></ul></ul><ul><ul><ul><ul><li>3.1.2.1 Introduction </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.1.2.2 Inputs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.1.2.3 Processing </li></ul></ul></ul></ul><ul><ul><ul><ul><li>3.1.2.4 Outputs </li></ul></ul></ul></ul><ul><ul><ul><ul><li>… </li></ul></ul></ul></ul>
  • 16. Prototype SRS Outline <ul><ul><li>3.2 External Interfaces Requirements </li></ul></ul><ul><ul><ul><li>3.2.1 User Interfaces </li></ul></ul></ul><ul><ul><ul><li>3.2.2 Hardware Interfaces </li></ul></ul></ul><ul><ul><ul><li>3.2.3 Software Interfaces </li></ul></ul></ul><ul><ul><ul><li>3.2.3 Communications Interfaces </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul><ul><ul><li>3.3 Performance Requirements </li></ul></ul><ul><ul><ul><li>Static: # of terminals, # of users, connections supported, amount of data stored/processed. </li></ul></ul></ul><ul><ul><ul><li>Dynamic: maximum allowed response time for processing events. </li></ul></ul></ul><ul><ul><li>3.4 Design Constraints </li></ul></ul><ul><ul><ul><li>3.4.1 Standard Compliance </li></ul></ul></ul><ul><ul><ul><li>Standards or regulations of the application domain with which the software must comply </li></ul></ul></ul><ul><ul><ul><li>3.4.2 Hardware Limitations </li></ul></ul></ul><ul><ul><ul><li>… </li></ul></ul></ul>
  • 17. Prototype SRS Outline <ul><ul><li>3.5 Software System Attributes </li></ul></ul><ul><ul><ul><li>3.5.1 Reliability </li></ul></ul></ul><ul><ul><ul><li>3.5.2 Availability </li></ul></ul></ul><ul><ul><ul><li>3.5.3 Security </li></ul></ul></ul><ul><ul><ul><li>3.5.4 Maintainability </li></ul></ul></ul><ul><ul><ul><li>3.5.5 Portability </li></ul></ul></ul><ul><ul><li>3.6 Other Requirements </li></ul></ul><ul><ul><ul><li>3.6.1 Data Base </li></ul></ul></ul><ul><ul><ul><li>3.6.2 Operations </li></ul></ul></ul><ul><ul><ul><li>3.6.3 … </li></ul></ul></ul><ul><li>4. Appendixes </li></ul><ul><li>5. Glossary </li></ul><ul><li>6. Index </li></ul>
  • 18. Requirements Validation <ul><li>The requirements actually define the system which the customer wants. </li></ul><ul><ul><li>Validity checks </li></ul></ul><ul><ul><ul><li>Requirements define one feature of the application </li></ul></ul></ul><ul><ul><li>Consistency checks </li></ul></ul><ul><ul><ul><li>Requirements shouldn’t conflict </li></ul></ul></ul><ul><ul><li>Completeness checks </li></ul></ul><ul><ul><ul><li>The requirements define all the functions of the software application </li></ul></ul></ul><ul><ul><li>Realism checks </li></ul></ul><ul><ul><ul><li>The software application can actually be implemented </li></ul></ul></ul><ul><ul><li>Verifiability checks </li></ul></ul><ul><ul><ul><li>The delivered application meets the requirements </li></ul></ul></ul>
  • 19. Requirement Validation Techniques <ul><li>Requirements Reviews </li></ul><ul><ul><li>Requirements are analyzed systematically by the QA. </li></ul></ul><ul><li>Software Prototyping </li></ul><ul><ul><li>User experiments with a model of a software application </li></ul></ul><ul><li>Test Case Generation </li></ul><ul><ul><li>if test cases may be generated </li></ul></ul><ul><li>Automated Consistency Analysis </li></ul><ul><ul><li>CASE Tools </li></ul></ul>
  • 20. Requirement Management <ul><li>Requirements review of the requirement document </li></ul><ul><ul><li>Formal </li></ul></ul><ul><ul><ul><li>Verifiability - testable </li></ul></ul></ul><ul><ul><ul><li>Comprehensibility – requirements properly understood? </li></ul></ul></ul><ul><ul><ul><li>Tractability – origin of the requirements </li></ul></ul></ul><ul><ul><ul><li>Adaptability </li></ul></ul></ul><ul><ul><li>Informal </li></ul></ul><ul><li>Definition – requirements management </li></ul><ul><ul><li>Process of understanding and controlling changes to requirements </li></ul></ul><ul><ul><li>Managing requirements change </li></ul></ul>
  • 21. Type of Requirements <ul><li>Enduring requirements </li></ul><ul><ul><li>Relatively stable, core attributes of a software application </li></ul></ul><ul><li>Volatile requirements </li></ul><ul><ul><li>Environment: policies, OS versions </li></ul></ul><ul><ul><ul><li>Mutable –environment of the organization </li></ul></ul></ul><ul><ul><ul><li>Emergent – emerge with the customer understanding </li></ul></ul></ul><ul><ul><ul><li>Consequential – another computer system - changes in an org processes </li></ul></ul></ul><ul><ul><ul><li>Compatibility – depends on a particular computer system or a business process </li></ul></ul></ul>
  • 22. Requirement Management Planning <ul><li>Requirements identification </li></ul><ul><ul><li>Identify the requirement so it can be referenced </li></ul></ul><ul><li>A change management process </li></ul><ul><ul><li>Asses the impacts and costs of the changes </li></ul></ul><ul><li>Tractability policy </li></ul><ul><ul><li>Relationships </li></ul></ul><ul><ul><ul><li>Among requirements </li></ul></ul></ul><ul><ul><ul><li>Requirements and design </li></ul></ul></ul><ul><li>CASE Tool Support </li></ul><ul><ul><li>Requirements storage </li></ul></ul><ul><ul><li>Change management </li></ul></ul><ul><ul><li>Traceability info management </li></ul></ul>
  • 23. Traceability info management 1. Source traceability info Stakeholders Rationale for requests Module Module Module 2. Requirements traceability info 3. Design traceability info Dependent links Stakeholders consulted <ul><li>Requirement text …. </li></ul><ul><li>Requirement text …. </li></ul><ul><li>Requirement text …. </li></ul>
  • 24. Requirements Management Tools

×