Your SlideShare is downloading. ×
SRS presenation by Group 6
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

SRS presenation by Group 6

467

Published on

Prensentation on Software requirements, are they really a problem

Prensentation on Software requirements, are they really a problem

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

  • Be the first to like this

No Downloads
Views
Total Views
467
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
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
  • Small system case helps us analyze a system because the environment can be controlled, the observation of outcomes is possible. What possibly affected the outcomes can be easily found out. And we can as a result, understand the system decisions easily.
  • Boilerplate is any text that is or can be reused in new contexts or applications without being changed much from the original.
    In computer programming, boilerplate is the term used to describe sections of code that have to be included in many places with little or no alteration. It is more often used when referring to languages which are considered verbose, i.e. the programmer must write a lot of code to do minimal jobs.
  • Transcript

    • 1. Software Requirements: Are They Really A Problem? Author:Author: T. E. Bell and T. A. ThayerT. E. Bell and T. A. Thayer TRW Defense and Space Systems, Group Redondo Beach, California
    • 2. Presented by Group 5  Humayun Kayesh ShamolHumayun Kayesh Shamol BIT-0114BIT-0114  Md. Iftekharul Alam EfatMd. Iftekharul Alam Efat BIT-0115BIT-0115  Mohammad IbrahimMohammad Ibrahim BIT-0117BIT-0117  Asif Imran AnikAsif Imran Anik BIT-0119BIT-0119  Amit Seal AmiAmit Seal Ami BIT-0122BIT-0122  Mirza Rehnuma TabassumMirza Rehnuma Tabassum BIT-0129BIT-0129 January 29, 2015 2 Software Requirement Specification & Analysis
    • 3. Outline:  IntroductionIntroduction  Software RequirementsSoftware Requirements  Characteristics of RequirementsCharacteristics of Requirements  Empirical DataEmpirical Data  Data LimitationsData Limitations  Small System CaseSmall System Case  Large System CaseLarge System Case January 29, 2015 3 Software Requirement Specification & Analysis
    • 4. Definition:  Software requirements are requirements orSoftware requirements are requirements or required activities which are essential for softwarerequired activities which are essential for software project development.project development.  To derive the requirements we need to have clearTo derive the requirements we need to have clear and thorough understanding of the products to beand thorough understanding of the products to be developed. This is prepared after detaileddeveloped. This is prepared after detailed communications with project team and thecommunications with project team and the customer.customer. January 29, 2015 4 Software Requirement Specification & Analysis
    • 5. Characteristics of Requirements January 29, 2015 5 Software Requirement Specification & Analysis
    • 6. Why software requirements are needed:  Effective requirements are very essentialEffective requirements are very essential for effective software project.for effective software project.  The problems caused by incorrect softwareThe problems caused by incorrect software requirement are often not identified at all.requirement are often not identified at all. January 29, 2015 6 Software Requirement Specification & Analysis
    • 7. Approaches of software requirement process: January 29, 2015 7 Software Requirement Specification & Analysis
    • 8. Development Phases of the System Development Cycle January 29, 2015 8 Software Requirement Specification & Analysis
    • 9. Empirical Data:  Derived from experiment and observationDerived from experiment and observation rather than theoryrather than theory  Information documented during the projectInformation documented during the project  Data collected during the project throughData collected during the project through observationobservation January 29, 2015 9 Software Requirement Specification & Analysis
    • 10. Problem Report:  Requirement deficiencies are written in theRequirement deficiencies are written in the problem reportsproblem reports  They are used to record the results ofThey are used to record the results of reviews or to request changesreviews or to request changes  Problem reports do not generally documentProblem reports do not generally document the correction of deficiencies but they dothe correction of deficiencies but they do record the symptoms of the problemrecord the symptoms of the problem January 29, 2015 10 Software Requirement Specification & Analysis
    • 11. Sources of Problem Reports January 29, 2015 11 Software Requirement Specification & Analysis
    • 12. Sources of Problem Reports:  Most of the problem reports are generatedMost of the problem reports are generated during reviews, during design and duringduring reviews, during design and during implementationimplementation  The same software requirements deficiencyThe same software requirements deficiency may be identified at any of several points inmay be identified at any of several points in the project lifethe project life January 29, 2015 12 Software Requirement Specification & Analysis
    • 13. Data Limitation January 29, 2015 13 Software Requirement Specification & Analysis
    • 14. Data Limitations in Software Requirement Problems report January 29, 2015 14 Software Requirement Specification & Analysis
    • 15. Limitations:  Develop project in undisciplined mannerDevelop project in undisciplined manner  Need for interpretation of textual materialsNeed for interpretation of textual materials  Insufficient information about the problemsInsufficient information about the problems causescauses January 29, 2015 15 Software Requirement Specification & Analysis
    • 16. Apparently no problem inApparently no problem in requirement existsrequirement exists January 29, 2015 16 Software Requirement Specification & Analysis
    • 17. Can't interpret problems into aCan't interpret problems into a general classified schemegeneral classified scheme January 29, 2015 17 Software Requirement Specification & Analysis
    • 18. Abstracting from unspecifiedAbstracting from unspecified problem statementproblem statement ““Something is wrong”Something is wrong” January 29, 2015 18 Software Requirement Specification & Analysis
    • 19. The Main ProblemThe Main Problem Not concerned about reason of problemsNot concerned about reason of problems in requirementin requirement January 29, 2015 19 Software Requirement Specification & Analysis
    • 20. Small System Case  Chosen because:Chosen because:  Environment can be controlledEnvironment can be controlled  Observation of outcomes is possibleObservation of outcomes is possible  Easily understandable system decisionsEasily understandable system decisions January 29, 2015 20 Software Requirement Specification & Analysis
    • 21. The Small System Case  A class divided to two teams by Dr. BoehmA class divided to two teams by Dr. Boehm  Requirements TeamRequirements Team  Design TeamDesign Team  All students received sameAll students received same ““Needs Statement”.Needs Statement”. January 29, 2015 21 Software Requirement Specification & Analysis
    • 22. January 29, 2015 22 Software Requirement Specification & Analysis
    • 23. Small System Case  Student Employment Information SystemStudent Employment Information System  accept and store information aboutaccept and store information about students' job qualifications andstudents' job qualifications and interestsinterests employers' available openingemployers' available opening  provide timely responses to students'provide timely responses to students' or employers' job-matching queriesor employers' job-matching queries January 29, 2015 23 Software Requirement Specification & Analysis
    • 24. Small System Case • Student Employment Information SystemStudent Employment Information System – track the progress of outstanding jobtrack the progress of outstanding job offersoffers – provide summary information on theprovide summary information on the job market to appropriate UCLAjob market to appropriate UCLA administratorsadministrators January 29, 2015 24 Software Requirement Specification & Analysis
    • 25. The progress  Both teams met their time limits.Both teams met their time limits.  BothBoth informalinformal and formal meetings tookand formal meetings took place between themplace between them  Record the problems by form (RPR)Record the problems by form (RPR) January 29, 2015 25 Software Requirement Specification & Analysis
    • 26. January 29, 2015 26 Software Requirement Specification & Analysis
    • 27. What happened in Observation… • Design team preparedDesign team prepared – two designstwo designs – Manual methodManual method • Batch data processing systemBatch data processing system • Noticeable factor:Noticeable factor: – Design team estimated a cost which isDesign team estimated a cost which is about half the original costabout half the original cost January 29, 2015 27 Software Requirement Specification & Analysis
    • 28. Impressive (?) Requirements Document  According to some senior TRW personnelAccording to some senior TRW personnel  Superior to most documentsSuperior to most documents  More problem specificMore problem specific  DirectDirect  CompleteComplete January 29, 2015 28 Software Requirement Specification & Analysis
    • 29. Analyzing Document in Detail  20 RPR used by design team20 RPR used by design team  32 Problems in reality32 Problems in reality  Estimated number of problems: 50 (byEstimated number of problems: 50 (by Boehm)Boehm)  Still an underestimationStill an underestimation January 29, 2015 29 Software Requirement Specification & Analysis
    • 30. January 29, 2015 30 Software Requirement Specification & Analysis
    • 31. Classification of Found Problems  Design team made 23 classificationsDesign team made 23 classifications  Authors made 32 classificationsAuthors made 32 classifications  Different definitions of classification byDifferent definitions of classification by author and design teamauthor and design team  Inconsistency-ambiguityInconsistency-ambiguity  Design constraining – IncorrectDesign constraining – Incorrect requirementrequirement January 29, 2015 31 Software Requirement Specification & Analysis
    • 32. Analyzing the Case  Most common problems are:Most common problems are:  AmbiguousAmbiguous  Design constrainingDesign constraining  Statistically total number of problems seemsStatistically total number of problems seems to be in excess of one (and probably into be in excess of one (and probably in excess of two) times the number of pages inexcess of two) times the number of pages in the requirements document.the requirements document. January 29, 2015 32 Software Requirement Specification & Analysis
    • 33. Large System Case January 29, 2015 33 Software Requirement Specification & Analysis
    • 34. Ballistic Missile Defense (BMD) January 29, 2015 34 Software Requirement Specification & Analysis
    • 35. Requirement Review:  1 million machine instructions1 million machine instructions  B-5 DocumentB-5 Document  Configuration Control Board (CCB)Configuration Control Board (CCB)  Classification of software error traceabilityClassification of software error traceability  STP development techniquesSTP development techniques January 29, 2015 35 Software Requirement Specification & Analysis
    • 36. Comparison: Software Requirements Problems Early STP Experience (1973) Software Requirements Problems Recent STP Experience (1975) January 29, 2015 36 Software Requirement Specification & Analysis
    • 37. Sample Requirement: January 29, 2015 37 Software Requirement Specification & Analysis
    • 38. January 29, 2015 Software Requirement Specification & Analysis 38
    • 39. Problem Strategy:  Categories 1-000 & 6-000Categories 1-000 & 6-000: register acceptable: register acceptable changeschanges  Category 2-000Category 2-000: violates technical & contractual: violates technical & contractual boundariesboundaries  Total of 722 problems reports & 972 uniqueTotal of 722 problems reports & 972 unique requirements out of 8248 general requirementrequirements out of 8248 general requirement (support paragraphs in the 2500 pages)(support paragraphs in the 2500 pages) January 29, 2015 39 Software Requirement Specification & Analysis
    • 40. Findings:  A huge number of requirementsA huge number of requirements  Details requirement for proper developmentDetails requirement for proper development  Change of requirement during projectChange of requirement during project lifetimelifetime  Good planning helps to reduce requirementGood planning helps to reduce requirement January 29, 2015 40 Software Requirement Specification & Analysis
    • 41. Requirement Challenges:  Difficult to control development environmentDifficult to control development environment  Long development timeLong development time  Large number of participantsLarge number of participants  Complex requirement specifications & analysisComplex requirement specifications & analysis phasephase  Large number of variables & control functionLarge number of variables & control function  Less supporting documentsLess supporting documents January 29, 2015 41 Software Requirement Specification & Analysis
    • 42. Reasons for Changing Requirements:  External reasonsExternal reasons  Social & political factorsSocial & political factors  Change in business & technologicalChange in business & technological environmentenvironment  Internal reasonsInternal reasons  Better understanding of functionalityBetter understanding of functionality  Marketing & other business viewpointsMarketing & other business viewpoints January 29, 2015 42 Software Requirement Specification & Analysis
    • 43. Categories of Requirement Problems:  MissingMissing  InadequateInadequate  UnclearUnclear  IncompleteIncomplete  AccuracyAccuracy  Criteria absentCriteria absent January 29, 2015 43 Software Requirement Specification & Analysis
    • 44. Quantity of Problems:  Sheer volume of problems encounteredSheer volume of problems encountered  Difficult to prioritize requirements due to large sizeDifficult to prioritize requirements due to large size  Unclearness in classification & organizationUnclearness in classification & organization  Difficult to document & keep track of theDifficult to document & keep track of the requirementsrequirements  Failure to identify critical problemsFailure to identify critical problems January 29, 2015 44 Software Requirement Specification & Analysis
    • 45. Ways to Solve Problems:  Good understandabilityGood understandability  Better organization & classificationBetter organization & classification  Resolving conflicts timelyResolving conflicts timely  Documenting requirementsDocumenting requirements  Use of requirement management software toolsUse of requirement management software tools January 29, 2015 45 Software Requirement Specification & Analysis
    • 46. Critical Review  Certain methods are outdated that have already been dealtCertain methods are outdated that have already been dealt withwith  Modules of data collection techniques deemedModules of data collection techniques deemed replaceablereplaceable  Negligible use of Requirements Management ToolsNegligible use of Requirements Management Tools  Requirement gathering methods like RPR replaceableRequirement gathering methods like RPR replaceable  Manual documentation replaced by automated toolsManual documentation replaced by automated tools  No mentioned use of case toolsNo mentioned use of case tools  RMT has already replaced CCB mentioned hereRMT has already replaced CCB mentioned here  Instant Retrieval of information have become automatedInstant Retrieval of information have become automated
    • 47. Critical Review(continued)  Requirements traceability is automatedRequirements traceability is automated  Change management process has becomeChange management process has become automatedautomated  Manual storage of data is outdatedManual storage of data is outdated  Identification of critical requirements haveIdentification of critical requirements have become automated as wellbecome automated as well
    • 48. January 29, 2015 48 Software Requirement Specification & Analysis
    • 49. January 29, 2015 49 Software Requirement Specification & Analysis

    ×