Published on

Requirement Engineering

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  2. 2. LEARNING TARGET What basic roles are there in RequirementsEngineering? What is a stakeholder? What are the tasks of RequirementsEngineering? What is the task of a Professional forRequirements Engineering? What characterizes a Professional forRequirements Engineering?2
  3. 3. 4.1 BASIC ROLES Client (= customer) a customer is an individual or organizationwho derives either direct or indirect benefitfrom a product The client formulates his needs ( BusinessRequirement , User Requirement) Contractor (= supplier) The contractor delivers solutions (RA)3
  4. 4. STAKEHOLDER A stakeholder is a person or a role that hasan interest Stakeholders can be either natural persons,legal entities or abstract persons Stakeholders often have conflicts of interestamong each other Important: Identification of all stakeholders inorder to take adequate consideration of allperspectives4
  5. 5. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (CUSTOMER RIGHTS ) To Expect Analysts to Speak Your Language To Have Analysts Learn About Your Businessand Objectives To Expect Analysts to Write a SoftwareRequirements Specification To Receive Explanations of RequirementsWork Products To Expect Analysts and Developers to TreatYou with Respect5
  6. 6. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (CUSTOMER RIGHTS ) To Describe Characteristics That Make theProduct Easy to Use To Be Given Opportunities to AdjustRequirements to Permit Reuse To Receive Good-Faith Estimates of theCosts of Changes To Receive a System That Meets YourFunctional and Quality Needs6
  7. 7. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (CUSTOMER RESPONSIBILITIES ) To Educate Analysts and Developers AboutYour Business To Spend the Time to Provide and ClarifyRequirements To Be Specific and Precise AboutRequirements To Make Timely Decisions To Respect a Developers Assessment ofCost and Feasibility7
  8. 8. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (CUSTOMER RESPONSIBILITIES ) To Set Requirement Priorities To Review Requirements Documents andEvaluate Prototypes To Promptly Communicate Changes to theRequirements To Follow the Development OrganizationsChange Process To Respect the Requirements EngineeringProcesses the Analysts Use8
  9. 9. RA ROLES Work collaboratively with customers, users,and system architects and designers toidentify the real requirements for a plannedsystem or software development effort todefine the problem that needs to be solved. Identifying the stated needs of customers andusers. Studying the business objectives9
  10. 10. RA ROLES Collaborating with customers and users in a jointor cooperative environment to analyze the statedrequirements, evolve better requirements, andprioritize them Involving system architects in requirementsdevelopment. Utilizing an industry-strength automatedrequirements tool to support this work.10
  11. 11. RA ROLES Work effectively with customers and users tomanage new and changed requirements sothat the project stays under control. Install amechanism to control changes. Be alert to new technologies that may help. Facilitate the project’s reuse of artifacts andachieving repeatability.11
  12. 12. RA ROLES Assist the project and its customers inenvisioning a growth path from the firstrelease or version of a product through a setof staged releases to the ultimate system orproduct. Advise the project (and customer) ofmethods, techniques, and automated toolsthat are available to best supportrequirements-related project work andactivities. 12
  13. 13. RA ROLES Use metrics to measure, track, and controlrequirements-related project work activitiesand results. Be able to facilitate discussions and tomediate conflicts. Study the domain of the area in which thesystem or software is being used.13
  14. 14. KNOWLEDGE OF A PROFESSIONAL FORREQUIREMENTS ENGINEERING: Skill of moderation Self-confident manner Ability to convince Language skills Ability to communicate Precision Analytical, clear thinking Ability to act in a structured way Methodological competence Stress resistance14
  15. 15. 4.2 TASKS OF REQUIREMENTS ENGINEERING Analysis of business processes Identification and analysis of requirements Quality assurance of requirements andspecifications Creation of the requirements specification Risk analysisThe Professional for Requirements Engineering identifieswishes and aims.15
  16. 16. ANALYSIS OF BUSINESS PROCESSES Analyze the business context Include thefollowing tasks: Analyze the customer organization’sbusiness enterprise to understand the: Business model. Organizational structure and relationships. Technology currently being used. Relevant planned improvements.16
  17. 17. ANALYSIS OF BUSINESS PROCESSES Analyze the competitor organizations thatproduce competing systems to: Identify, profile, analyze, and understand thecompetitors. See how the planned system [upgrade] willimprove the customer organization’s businessenterprise and help it compete.17
  18. 18. ANALYSIS OF BUSINESS PROCESSES Analyze current and potential/plannedmarketplaces Analyze critical technologies Analyze current and intended future usercommunities (to understand their needs anddesires and determine how the system mightimprove their tasks and workflows)18
  19. 19. ANALYSIS OF BUSINESS PROCESSES Analyze the stakeholders to: Identify different stakeholder persons, roles,organizations, and systems. Profile them including categorizing them intowell-defined and well understood groups. Understand their needs, desires,responsibilities, and tasks.19
  20. 20. ANALYSIS OF BUSINESS PROCESSES Develop a business case to determinewhether the system [enhancement] shouldbe developed by Determining is costs and benefits Comparing its merits relative to those ofcompeting systems.20
  21. 21. ANALYSIS OF BUSINESS PROCESSES VISIONING During this task, the mainRE team collaborates with keystakeholders to produce a vision of thenew systemDefine the system’s mission.Determine the business problems andopportunities to be solved by the system.Determine the most important stakeholderneeds to be fulfilled by the system.21
  22. 22. VISIONINGDetermine the most important business,functional, and quality goals of the system.Determine any major business, technical,and legal/regulatory constraints on thesystem. Use this information to build a consensusamong key system stakeholders regardingthe vision of the system to lay a foundationon which the system requirements can beengineered.22
  23. 23. IDENTIFICATION AND ANALYSIS OFREQUIREMENTS Requirement Identification : During thistask, the RE teams identify potentialrequirements include: Identify sources of requirements(e.g., stakeholders, documents, legacysystems, problem reports, etc). Elicit needs, goals, desires, and requirementsfrom a representative sample of all majorstakeholder types23
  24. 24. REQUIREMENT IDENTIFICATION Gather potential requirements from existingdocuments describing legacy or competingsystems, problem reports, marketing surveys,and other sources. Invent new requirements so that the system willbe truly better than the legacysystems it willreplace and therefore worth building. Invention isa critically important, though underutilized,technique for identifying requirements, and isoften the difference between a highly successfulsystem and a marginally successful system.24
  25. 25. REQUIREMENT IDENTIFICATION Transform stakeholderdesires, expectations, and needs intoinformal, textual, potential requirements.25
  26. 26. REQUIREMENTS IDENTIFICATION During this task, the RE teams identifypotential requirements. This task typicallyincludes the following subtasks: Identify sources of requirements(e.g., takeholders, documents, legacysystems,problem reports, etc). Elicit needs, goals, desires, and requirementsfrom a representative sample of all majorstakeholder types26
  27. 27. REQUIREMENTS IDENTIFICATION Gather potential requirements from existingdocuments describing legacy or competingsystems, problem reports, marketingsurveys, and other sources. Invent new requirements so that the system willbe truly better than the legacy systems it willreplace and therefore worth building Transform stakeholderdesires, expectations, and needs intoinformal, textual, potential requirements.27
  28. 28. REQUIREMENTS REUSE During this task, the RE teams reuse all orpart of preexisting requirements workproducts. This task typically includes thefollowing subtasks: Identify any potentially relevant reusablerequirements work products (e.g., individualrequirements, requirementstemplates, requirements diagrams, requirementsmodels, and requirements specificationscomplete work products + parts of workproducts 28
  29. 29. REQUIREMENTS REUSE Evaluate the identified reusable requirementswork products for relevancy to the currentendeavor. Tailor the relevant identified reusablerequirements work products to meet the needs ofthe current endeavor. Reuse the tailored reusable work products byincorporating them into the current endeavor’srequirements work products.29
  30. 30. REQUIREMENTS ANALYSIS During this task, the RE teams analyze theidentified and reused requirements. Include: Study, categorize, decompose and organize,model, quantify, refine, prioritize, justify, andtrace each requirement to its source(s). Transform informal textual requirements intosemiformal or formal requirements (if formalmethods are used).30
  31. 31. REQUIREMENTS ANALYSIS Negotiate the prioritization of requirements withthe requirements stakeholders, and use thenegotiated prioritization to help schedule theimplementation of the requirements. Note thatthis subtask is often performed concurrently withthe requirements validation task. Verify any related assumptions.31
  32. 32. REQUIREMENTS ANALYSIS Transform potential raw requirements andrelated information into real requirements thathave the necessary quality characteristics suchas clarity (i.e.,lack of ambiguity), completeness,consistency, correctness, feasibility(e.g.,technical, financial, schedule, etc.),verifiability, and understandability. Ensure that the requirements are sufficiently wellunderstood that they can be properly specified.32
  33. 33. REQUIREMENTS PROTOTYPING (OPTIONAL) During this task, the RE teams generaterequirements engineering prototypes. Include: Produce one or more requirements prototypes(e.g., paper or wireframe prototypes of userinterfaces or executable models). Evaluate these prototypes. This may involveanalysis of static prototypes or execution andevaluation of dynamic prototypes.33
  34. 34. REQUIREMENTS PROTOTYPING (OPTIONAL) Use these prototypes to: Help identify new requirements such asfunctional, data, and quality requirementsregarding user interfaces. Better understand existing requirements. Identify defects in the existing requirements thatdrove the development of these prototypes. Support the analysis of these requirements.34
  35. 35. REQUIREMENT ANALYSIS PROCEDURE1. Analysis of the needs2. Description of the solution3. Cost estimate and prioritization35
  36. 36. 7.2 METHODS AND TECHNIQUES Different aspects of a system arerepresented through different views Models are developed through suitablemethods of analysis Differentiation between types of models Requirements models Solution models36
  37. 37. DIFFERENT MODELS (STRUCTURED) Context model Functional decomposition Data flow model State transition model Petri Net Entity Relationship Model37
  38. 38. CONTEXT MODEL Is a diagram that represents the actorsoutside a system that could interact with thatsystem This diagram is the highest level view of asystem. SCDs show a system, often software-based, as a whole and its inputs and outputsfrom/to external factors38
  39. 39. 39
  40. 40. FUNCTIONAL DECOMPOSITION A Functional Decomposition Diagramenables you to view your system functions inan hierarchical structure40
  41. 41. 41
  42. 42. DATA FLOW MODEL DFDs show the flow of data from externalentities into the system, showed how thedata moved from one process to another, aswell as its logical storage42
  43. 43. 43
  44. 44. STATE TRANSITION MODEL describe the behavior of systems State diagrams require that the systemdescribed is composed of a finite number ofstate44
  45. 45. 45
  46. 46. PETRI NET Like the activity diagram46
  47. 47. ENTITY RELATIONSHIP MODEL is an abstract and conceptual representationof data. Entity-relationship modeling is adatabase modeling method, used to produce a type of conceptualschema or semantic data model of asystem, often a rational database, and itsrequirements in a top-down fashion47
  48. 48. 48
  49. 49. 7.3 OBJECT-ORIENTED ANALYSIS UML (Unified Modeling Language) UML provides diagrams for different views ofthe system Use case diagrams, class diagrams, activitydiagrams, state diagrams, object diagrams,sequence diagram, component diagrams,package diagrams, etc.49
  50. 50. USE-CASE DIAGRAM Use-Case diagrams are probably thesimplest diagramming notation within theUML Use-Case diagrams model the operations ofthe system as perceived by an outside user i.e. They model ‘what’ the system does ratherthan ‘how’ it does it !50
  51. 51. USE-CASE DIAGRAM The two primary elements of UC diagrams are Actorsand Use-Cases Actors - (shown as stick-men on diagrams) Model the outside users of the system Actors are not always humans, can be othercomputer systems; external devices etc. A single user may actually be a different actor at thesame time Many users may be the same actor at the same time It is actors that initiate a particular use-case51
  52. 52. USE-CASE DIAGRAM Use-Cases - (shown as an ellipse on diagrams) A use-case is a unit of an externally visibleoperation (i.e. a single use of the system) Each use-case is orthogonal within the model(i.e. each use-case can be performedindependently and in any order) Each use-case can connect to one or moreactors by a solid line, this indicates anassociation between an actor and that particularuse of the system52
  53. 53. USE-CASE DIAGRAM EXAMPLE53OpenAccountCloseAccountCreditAccountDebitAccountPrintStatementAccountsmanagerTellerATMBankSystem
  54. 54. REFINING USE-CASE DIAGRAMS Once an initial use-cases have been documentedthey can be refined The refining of a Use-Case diagram can helpsimplify and remove unnecessary redundancy There are three main ways in which refinement canbe performed (usually aided by readingdescriptions, see later) Identification of shared sequences of operations Identification of alternative actions within single use-cases Identification of common behavior between use-cases54
  55. 55. USING <<INCLUDE>> ASSOCIATIONS This type of association allows a sharedsequence of operations to be included in severaluse-cases Simplifies a use-case diagram by factoring outcommon operations When a use-case is included within anotheruse-case the operations are alwaysincorporated The operations from the included use-case areNOT interleaved, they exist as a single block Including a use-case is similar to calling a sub- 55
  56. 56. <<INCLUDE>> EXAMPLE56OpenAccountCloseAccountCreditAccountDebitAccountPrintStatementAccountsmanagerTellerATMBankSystemCheckAccountBalance
  57. 57. USING <<EXTEND>> ASSOCIATIONS This type of association allows a sequence ofoperations to be conditionally included in a use-case Improves the model by identifying less commonalternatives to operations normally performed Extensions are typically attached to anextension-point within the use-case which isbeing extended If a specific condition is true at the extensionpoint then the extending use-cases operationsare included, otherwise they are not Similar to an ‘if-then’ construct within a program57
  58. 58. <<EXTEND>> EXAMPLE58OpenAccountCloseAccountCreditAccountDebitAccountPrintStatementAccountsmanagerTellerATMBankSystemCheckAccountBalanceRejectRequest
  59. 59. USING GENERALIZATION/SPECIALIZATION This type of association allows common behaviorto be extracted into generalized use-cases The common behavior is then inherited byspecialized use-cases Additional steps in the specialized use-cases canbe interleaved with those inherited from thegeneralized use-case A specialized use-case inherits associations fromits generalized use-case, and can be substitutedfor its generalized use-case
  60. 60. GENERALIZATION/SPECIALIZATION EXAMPLEOpenAccountCloseAccountCreditAccountDebitAccountPrintStatementAccountsmanagerTellerATMBankSystemCheckAccountBalanceTransferFundsRejectRequest
  61. 61. INTERNALS OF USE-CASES Use-Case diagrams do not show internalworkings of each use-case These can be documented using other UMLdiagrams or natural language Tend to use natural language during analysis andUML diagrams later in the lifecycle Natural language descriptions should be well-formed and consist of an agreed upon formatwithin the s/w company
  62. 62. A FORMAT DEFINITION FOR TEXTUAL USE-CASE DESCRIPTIONSList all pre-conditionsX-reference name of any generalized use-caseList main sequence of operations (numbered)Show included use-cases as single step, X-ref the nameList alternativesX-ref the sequence number of extension pointSpecify condition for extension to be utilizedX-reference the sequence number of re-entrance point
  63. 63. EXAMPLE DOCUMENTATION OF A USE-CASEUse-case : debit accountInherits from : Transfer Fundspre-condition: account number exists1. Read amount to be debited2. Perform check (Check AccountBalance)3. Deduct amount to be debited4. Report success code
  64. 64. USE-CASE SUMMARY Accurate requirements are very important to thesuccess of analysis and design Use-Case diagrams can be used to modelrequirements as seen from an external, or users’point of view Actors & Use-Cases are the two primary elementsof a Use-Case diagram Refinement of a Use-Case diagram helps removeredundancy Internals of each use-case can be defined usingother UML diagrams and/or natural language
  65. 65. ACTIVITY DIAGRAM Activity diagram is used to display thesequence of activities Activity Diagrams show the workflow from astart point to the finish point detailing themany decision paths that exist in theprogression of events contained in theactivity They may be used to detail situations whereparallel processing may occur in theexecution of some activities Activity Diagrams are useful for BusinessModeling where they are used for detailingthe processes involved in business activities65
  66. 66. 66
  67. 67. ACTIVITY NODE An activity is the specification of aparameterized sequence of behavior An activity is shown as a round-corneredrectangle enclosing all the actions, controlflows and other elements that make up theactivity67
  68. 68. ACTION NODE An action represents a single step within anactivity Actions are denoted by round-corneredrectangles.68
  69. 69. ACTION CONSTRAINTS Constraints can beattached to anaction This sample showsan action with localpre and post-conditions.69
  70. 70. CONTROL FLOW A control flow shows the flow of control fromone action to the next one Its notation is a line with an arrowhead.70
  71. 71. INITIAL NODE An initial or start node is depicted by a largeblack spot, as depicted below71
  72. 72. ACTIVITY FINAL NODE There are two types of final node activity final flow final nodes The activity final node is depicted as a circlewith a dot inside72
  73. 73. FLOW FINAL NODE The flow final node is depicted as a circlewith a cross inside The difference between the two node typesis that the flow final node denotes the end ofa single control flow The activity final node denotes the end of allcontrol flows within the activity73
  74. 74. SAMPLES OF ACTIVITY AND FLOW FINAL NODES A flow dies without ending the whole activity A flow final node terminates its own path notthe whole activity It is shown as a circle with an X through it74
  75. 75. BASIC CONTROL FLOWS Sequential Control Flow Branch Control Flow Iteration Control Flow75
  76. 76. SEQUENTIAL CONTROL FLOW A Sequence of Activities Node Unconditional Flow76
  77. 77. BRANCH CONTROL FLOW Decision nodes and merge nodes have thesame notation - using a diamond shape They can both be named The control flows coming away from adecision node will have guard conditionswhich will allow control to flow if the guardcondition is met77
  78. 78. DECISION NODE Decisions are used when you want toexecute a different sequence of actionsdepending on a condition Decisions are drawn as diamond-shapednodes with one incoming edge and multipleoutgoing edges Each branched edge contains a guardcondition written in brackets Guard conditions determine which edge istaken after a decision node78
  79. 79. 79
  80. 80. MERGE NODE The branched flows join together at a mergenode, which marks the end of the conditionalbehavior started at the decision node Merges are also shown with diamond-shaped nodes, but they have multipleincoming edges and one outgoing edge80
  81. 81. USING MERGE NODE IN UML2 In UML 2.0, its better to be as clear aspossible and to show merge nodes81
  83. 83. ITERATION CONTROL FLOW A loop is a sequence of activity nodes whichis specified once but which may be carriedout several times in succession83
  84. 84. CONCURRENT ACTIVITIES Forks and Joins have the same notation –using either a horizontal or vertical bar They indicate the start and end of concurrentthreads of control84
  85. 85. CONCURRENT ACTIVITY When actions occur in parallel, it doesntnecessarily mean they will finish at the sametime In fact, one task will most likely finish beforethe other However, the join prevents the flow fromcontinuing past the join until all incomingflows are complete85
  86. 86. 86
  87. 87. CLASS DIAGRAM87
  88. 88. STATE DIAGRAM88
  89. 89. 7.4 COST ESTIMATES Cost estimates connect RequirementsEngineering with the project managementTypes of estimate Costs Time Requirements Quality Cost estimates help to recognize the cost forchange89
  90. 90. ESTIMATION PROCEDURE Conclusions by analogy Algorithmic procedure Function point procedure bottom-up Approach Estimation procedures are always based onhistorical data and framework conditions90
  91. 91. 7.5 PRIORITIZATION Why prioritization? Prioritization is a way to deal with competingdemands for limited resources A project manager must balance the desiredproject scope against the constraints ofschedule, budget, staff, and quality goals.One way to accomplish this is to drop—or todefer to a later release—low-priority91
  92. 92. GAMES PEOPLE PLAY WITH PRIORITIES Customers and developers both shouldprovide input to requirements prioritization customers will establish perhaps 85 percentof the requirements as high priority, 10percent as medium, and 5 percent as low. High priority mean high risk.92
  93. 93. ENCOURAGE CUSTOMER TO IDENTIFY LOWPRIORITY REQUIREMENT ask questions such as the following: Is there some other way to satisfy the need thatthis requirement addresses? What would the consequence be of omitting ordeferring this requirement? What would the impact be on the projectsbusiness objectives if this requirement werentimplemented immediately? Why would a user be unhappy if this requirementwere deferred to a later release?93
  94. 94. A PRIORITIZATION SCALE common prioritization approach groupsrequirements into three categories One way to assess priority is to consider thetwo dimensions of importance and urgency High priority requirements are both important(the user needs the capability) and urgent (theuser needs it in the next release). Contractual orlegal obligations might dictate that therequirement must be included, or there might becompelling business reasons to implement itpromptly.94
  95. 95. A PRIORITIZATION SCALE Medium priority requirements are important (theuser needs the capability) but not urgent (theycan wait for a later release). Low priority requirements are not important (theuser can live without the capability if necessary)and not urgent (the user can wait, perhapsforever). Requirements in the fourth quadrant appear tobe urgent but they really arent important. Dontwaste your time working on these. They dontadd sufficient value to the product.95
  96. 96. Important Not ImportantUrgent HighPriorityLow PriorityNotUrgentMediumPriorityDont do these!96REQUIREMENTS PRIORITIZATION BASEDON IMPORTANCE AND URGENCY
  97. 97. PRIORITIZATION BASED ON VALUE, COST, ANDRISK The typical participants in the prioritizationprocess include: The project manager, who leads theprocess, arbitrates conflicts, and adjusts inputfrom the other participants if necessary Customer representatives, such as productchampions or marketing staff, who supply thebenefit and penalty ratings Development representatives, such as teamtechnical leads, who provide the cost and riskratings97
  98. 98. STEPS OF THE PRIORITIZATION MODEL Step 1: List in the spreadsheet all the features, usecases, or requirements that you want toprioritize; All the items must be at the same levelof abstraction—dont mix functional requirementswith product features. If certain features are logically linked (forexample, youd implement feature B only iffeature A were included), list only the driving feature in the analysis. If you have more items than that, group relatedfeatures together to create a manageable initiallist. 98
  99. 99. STEPS OF THE PRIORITIZATION MODEL Have your customer representativesestimate the relative benefit that each featurewould provide to the customer or to thebusiness on a scale of 1 to 9. A rating of 1indicates that no one would find it useful and9 means it would be extremely valuable.These benefit ratings indicate alignment ofthe features with the products businessrequirements.99
  100. 100.  Estimate the relative penalty that thecustomer or business would suffer if thefeature were not included. Again, use a scaleof 1 to 9. A rating of 1 means that no one willbe upset if its excluded; 9 indicates a seriousdownside. When assigning penaltyratings, consider how unhappy thecustomers will be if a specific capability isntincluded. Ask yourselves questions such asthe following:100STEPS OF THE PRIORITIZATION MODEL
  101. 101. ESTIMATE THE RELATIVE PENALTY Would your product suffer in comparison with otherproducts that do contain that capability? Would there be any legal or contractualconsequences? Would you be violating some government or industrystandard? Would users be unable to perform some necessaryor expected functions? Would it be a lot harder to add that capability later asan enhancement? Would problems arise because marketing haspromised a feature to satisfy some potential101
  102. 102. STEPS OF THE PRIORITIZATION MODEL By default, benefit and penalty are weightedequally. As a refinement, you can change therelative weights for these two factors102
  103. 103. STEPS OF THE PRIORITIZATION MODEL Have developers estimate the relative cost ofimplementing each feature, again on a scaleof 1 (quick and easy) to 9 (time consumingand expensive). Developers estimate thecost ratings based on the featurescomplexity, the extent of user interface workrequired, the potential ability to reuse existingcode, the amount of testing anddocumentation that will be needed, and soforth.103
  104. 104. STEPS OF THE PRIORITIZATION MODEL Similarly, have developers rate the relativedegree of technical or other risks associatedwith each feature on a scale of 1 to 9.Technical risk is the probability of not gettingthe feature right on the first try. A rating of 1means that you can program it in your sleep.A 9 indicates serious concerns aboutfeasibility, the lack of staff with the necessaryexpertise, or the use of unproven orunfamiliar tools and technologies.104
  105. 105. STEPS OF THE PRIORITIZATION MODEL Once youve entered all the estimates intothe spreadsheet, it will calculate a priorityvalue for each feature using the followingformula: priority = value %(cost % * cost weight) + (risk % * risk weight)105
  106. 106. SPECIFICATION OF REQUIREMENTS In the specification, requirements arespecified in a structured way and aremodeled separately. The specification serves to track andmanage requirements.106
  107. 107. CREATION OF THE REQUIREMENTSSPECIFICATION During this task, the RE teams generate andpublish analyzed and/or validatedrequirements in paper or electronicrequirements specification documents.Include: System, subsystem, software, and hardwarerequirements specifications containing theindividual requirements and associated ancillaryinformation.107
  108. 108. CREATION OF THE REQUIREMENTSSPECIFICATION Operational concept documents (OCDs)containing use cases, misuse or abuse cases,and usage scenarios. Glossary and Domain Object Model to properlydefine the meaning of the terms used in therequirements108
  109. 109. CREATION OF THE REQUIREMENTSSPECIFICATION Distribute the requirements specifications to theiraudiences or make access available to them. Iterate the requirements specifications as aresult of informal feedback. Note that moreformal feedback will come as part of therequirements verification subtask of qualityengineering.109
  110. 110. STANDARD CONTENTS OF A REQUIREMENTSDOCUMENT Introduction Secrecy clause Regulations Standards Stakeholder Purpose of the product Description of the system110
  111. 111. STANDARD CONTENTS OF A REQUIREMENTSDOCUMENT Functional requirements Non-functional requirements Assumptions Dependencies Risks Safety requirements Software Quality Attributes Acceptance111
  112. 112. LEVEL OF SPECIFICATION Requirements specifications Are also called performance specifications The creation should be the customers task Solution specifications Are also called functional specifications The basis for the further system development112
  113. 113. SPECIFICATION PROCEDURE Specification as an activity for formalizing theresults of the requirements analysis Different degrees of formalization Non-formal Semi-formal Formal113
  114. 114. REQUIREMENTS MANAGEMENT During this task, the RE teams manage allrequirements, regardless of their status. Record and store the requirements and theirattributes (i.e., metadata about the requirements)in an appropriate repository, database, orrequirements management tool. Control access(e.g., create, read, update, delete) to therequirements (e.g., based on metadata such asauthorization to create/read/update/deleterequirements by role, requirementstate, requirement ownership, requirementresponsibility, date of last change to therequirement, etc.). 114
  115. 115. REQUIREMENTS MANAGEMENT Negotiate with the stakeholders to eliminate anyinconsistencies between requirements and theirpriorities. Report the status of the requirements (e.g., thenumber, percentage, and state of therequirements and requirements categories). Trace the requirements (e.g., to the associatedarchitecture, design, implementation, and testwork products).115
  116. 116. REQUIREMENTS VALIDATION During this task, the RE teams validate thecorrectness of the analyzed requirementswith their stakeholders and make anynecessary corrections. This is an ongoing task116
  117. 117. REQUIREMENTS VALIDATION Identify a representative sample of all majorstakeholder types(e.g., customers, users, maintainers, operators, subject matter experts, marketers, and certifiers)to validate the requirements. Ensure these stakeholders validate thecorrectness of the requirements. Iterate to fix any requirements problems. Certify that the requirements are an acceptabledescription of the system, softwareapplication, or component to be implemented.117
  118. 118. RELATED TASKS FROM OTHER DISCIPLINES Scope Management is the management taskthat manages requirements changes thatcould significantly change the scope of theendeavor. Requirements Verification is the qualityengineering task that controls the quality ofthe requirements and other requirementswork products such as requirements modelsand requirements specifications.118
  119. 119. RELATED TASKS FROM OTHER DISCIPLINES Requirements Configuration Control is theconfiguration management task thatmanages and evaluates the impact ofproposed changes to base-linedrequirements and other requirements workproducts.119
  120. 120. RELATIONSHIP BETWEEN THESE TASKS Iterative in the sense that the same tasks willtypically need to be repeated on the samework products in order to fix defects andmake other improvements. Incremental in the sense that most systemsare too large and complex to engineer allrequirements in a big-bang waterfall mannerbefore beginning the tasks of otherdisciplines120
  121. 121. RELATIONSHIP BETWEEN THESE TASKS Concurrent in the sense that: Requirements engineering tasks are performedsimultaneously with the tasks of many otherdisciplines The requirements engineering teams rapidlycycle between tasks while different members ofthe requirements team concurrently performdifferent tasks on different sets of requirements.121
  122. 122. RELATIONSHIP BETWEEN THESE TASKS When developing large and complex systems,different requirements engineering teams areconcurrently performing different requirementsengineering tasks on different components of thesystem architecture at different levels of thesystem architecture.122
  123. 123. REQUIREMENTS TRACKING Requirements traceability is concerned withdocumenting the life of a requirement and toprovide bi-directional traceability betweenvarious associated requirements. It enables users to find the origin of eachrequirement and track every change whichwas made to this requirement. it may be necessary to document everychange made to the requirement123
  124. 124. GOTEL AND FINKELSTEIN DEFINITION the ability to describe and follow the life of arequirement, in both a forward and backwarddirection (i.e. from its origin, through itsdevelopment and specification, to itssubsequent deployment and use, andthrough periods of on-going refinement anditeration in any of these phases)124
  125. 125. 8.1 TRACING WITHIN THE PROJECT Traceability Requirements are not stable, but continue todevelop Reasons for continued development New insights New customer needs Continued work New connections within the project125
  126. 126. TRACEABILITY AS A SOLUTION: Provides a check that all important steps ofthe development process have been carriedout Goals: Impact analysis, coverage analysis, use-of-potential analysis, proof of implementation, useof the requirement, etc. In order to ensure good traceability, it isimportant to label the requirements precisely.126
  127. 127. PRE – AND POST- TRACIBILITY A SRS (software requirements specification)is traceable if the origin of each of itsrequirements is clear and if it facilitates thereferencing of each requirement in futuredevelopment and enhancementdocumentation each requirement to be traced to its origin inother documents and to the softwarecomponent( s) satisfying the requirement.127
  128. 128. 128
  129. 129. TYPES OF TRACEABILITY backward from requirements traceability (pre-traceability) implies that we know why everyrequirement in the SRS (SoftwareRequirements Specification) exists. It impliesthat each requirement explicitly references itssource in previous documents; forward from requirements traceability (post-traceability) implies that we understand whichcomponents of the software satisfy eachrequirement. It demands that each requirementin the SRS explicitly references a design129
  130. 130. TYPES OF TRACEABILITY backward to requirements traceability (pre-traceability) implies that every softwarecomponent explicitly references thoserequirements that it helps to satisfy. It impliesthat each requirement in the SRS has a uniquename or reference number; forward to requirements traceability (post-traceability) implies that documents thatpreceded the SRS can reference the SRS. Like"back to requirements" traceability, this impliesthat each requirement in the SRS has a uniquename or reference number;"130
  131. 131. TYPES OF TRACEABILITY Horizontal tracing Horizontal traceability ensures that therequirements are traceable to the test cases. vertical tracing Vertical traceability ensures that the requirements aretraceable to the components of the implemented systemand vice versa.131
  132. 132. 132
  133. 133. 8.2 CHANGE MANAGEMENT Changes of the requirements (ChangeManagement) Changes are checked and decided on by aChange Control Board Makes decisions regarding change requests133
  134. 134. THE CHANGE CONTROL BOARD consists of Project management Development Quality assurance Business management, if applicable Customer, if applicable etc.134
  135. 135. THE CHANGE CONTROL A structured process is necessary forchanges of requirements The analysis of the meaning of each changeis important. Hasty solutions are problematic. Large changes of the requirements can beso serious that they represent a contractualchange.135
  136. 136. 8.3 METRICS Metrics make it possible to make aquantifiable statement regarding the projectstatus and quality Classification figures must always becompared to reference data136
  137. 137. METRICS FOR REQUIREMENTS: Project costs Project tracking Project stability Process improvement Quality of the specification Number of errors Type of error137
  138. 138. MEASUREMENT OF THE REQUIREMENTSQUALITY Are the requirements correct? Are the requirements understandable? The higher the change rate, the more aproject is at risk138
  139. 139. RISK MANAGEMENT Project risk management is the art and scienceof identifying, analyzing, and responding to riskthroughout the life of a project and in the bestinterests of meeting project objectives Risk management is often overlooked inprojects, but it can help improve project successby helping select good projects, determiningproject scope, and developing realisticestimates139
  140. 140. 3.2 WHY RISK MANAGEMENT minimize the impact of project threats seize the opportunities that occur deliver your project on time, on budget andwith the quality results your project sponsordemands team members will be much happier if theydo not enter a "fire fighting" mode140
  141. 141. RISK MANAGEMENT GOLDEN ROLES Make Risk Management Part of Your Project Identify Risks Early in Your Project Communicate About Risks Consider Both Threats and Opportunities Clarify Ownership Issues Prioritize Risks Analyze Risks141
  142. 142. RISK MANAGEMENT GOLDEN ROLES Plan and Implement Risk Responses Register Project Risks142
  143. 143. REQUIREMENTS-RELATED RISKSREQUIREMENTS ELICITATION Product vision and project scope Time spent on requirements development (arough guideline is to spend about 10 to 15percent of your project effort on requirementsdevelopment activities ) Completeness and correctness ofrequirements specifications (apply the use-case technique to elicit requirements byfocusing on user tasks)143
  144. 144. REQUIREMENTS-RELATED RISKSREQUIREMENTS ELICITATION Requirements for highly innovativeproducts (Emphasize market research, buildprototypes, and use customer focus groups ) Defining non-functional requirements (Querycustomers about quality characteristics ) Customer agreement on productrequirements (Determine who the primarycustomers are, Make sure youre relying onthe right people for decision-making authorityon the requirements )144
  145. 145. REQUIREMENTS-RELATED RISKSREQUIREMENTS ELICITATION Unstated requirements (Customers oftenhold implicit expectations that are notcommunicated or documented ) Existing product used as the requirementsbaseline (Document the requirements thatyou discover through reverseengineering, and have customers reviewthose requirements to ensure that they arecorrect and still relevant )145
  146. 146. REQUIREMENTS-RELATED RISKSREQUIREMENTS ELICITATION Solutions presented as needs (The analystmust drill down to understand the intentbehind a solution the customer haspresented )146
  147. 147. REQUIREMENTS-RELATED RISKSREQUIREMENTS ANALYSIS Requirements prioritization (Ensure thatevery functional requirement, feature, or usecase is prioritized and allocated to a specificsystem release or iteration ) Technically difficult features (Evaluate thefeasibility of each requirement to identifythose that might take longer than anticipatedto implement )147
  148. 148. REQUIREMENTS-RELATED RISKSREQUIREMENTS ANALYSIS Unfamiliar technologies, methods,languages, tools, or hardware (Dontunderestimate the learning curve of gettingup to speed with new techniques that areneeded to satisfy certain requirements )148
  149. 149. REQUIREMENTS-RELATED RISKSREQUIREMENTS SPECIFICATION Requirements understanding (Formalinspections of requirements documents byteams that include developers, testers, andcustomers , experienced requirementsanalysts , Models and prototypes ) Time pressure to proceed despiteTBDs (Record the name of the personresponsible for closing each TBD and thetarget date for resolution )149
  150. 150. REQUIREMENTS-RELATED RISKSREQUIREMENTS SPECIFICATION Ambiguous terminology (Create a datadictionary that defines the data items andstructures ) Design included in requirements (Review therequirements to make sure they emphasizewhat needs to be done to solve the businessproblem, rather than stating how it will besolved. )150
  151. 151. REQUIREMENTS-RELATED RISKSREQUIREMENTS VALIDATION Invalidated requirements (Gain commitmentfrom your customer representatives toparticipate in requirements inspections ) Inspection proficiency ( Train all teammembers , Invite an experienced inspector )151
  152. 152. REQUIREMENTS-RELATED RISKSREQUIREMENTS MANAGEMENT Changing requirements ( deferimplementation of those requirements thatare most likely to change, and design thesystem for easy modifiability ) Requirements change process (not having adefined change process, using an ineffectivechange mechanism, and incorporatingchanges that bypass the process )152
  153. 153. REQUIREMENTS-RELATED RISKSREQUIREMENTS MANAGEMENT Unimplemented requirements (Therequirements traceability matrix ) Expanding project scope ( use incrementaldelivery life cycle )153