Requirement Engineering

Requirement EngineeringTeknik Informatika Universitas Telkom20151

12-CRS-0106 REVISED 8 FEB 2013

1

OutlineRequirement Engineering Requirement Engineering TaskInceptionElicitationElaborationNegotiationSpecificationValidationRequirement Management

2

12-CRS-0106 REVISED 8 FEB 2013http://agile.dzone.com/articles/gossip-game-requirements?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fphp+%28PHP+Zone%292

Requirement EngineeringRE helps software engineer to better understand the problem they will work to solveParticipant : Software Engineers, managers, customers and end usersRE is a software engineering action that begin during the communication activity and continues into the modeling activity

3

12-CRS-0106 REVISED 8 FEB 2013

3

Requirement EngineeringProvides the appropriate mechanism for :Understanding what the customer wantAnalyzing needAssessing feasibilityNegotiating a reasonable solutionSpecifying a solution unambiguouslyValidating the specificationManaging the requirement as they are transformed into an operational system4

12-CRS-0106 REVISED 8 FEB 2013Requirement Engineering TaskInceptionElicitationElaborationNegotiationSpecificationValidationManagement5

12-CRS-0106 REVISED 8 FEB 2013RE Task : Inceptionask a set of questions that establish basic understanding of the problemthe people who want a solutionthe nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developer

6

12-CRS-0106 REVISED 8 FEB 2013RE Task : Inception (cont.)Inception process :Identify stakeholderswho else do you think I should talk to?Recognize multiple points of viewWork toward collaborationthe effectiveness of preliminary communication and collaboration between the customer and the developerAsking The first questionsWho is behind the request for this work?Who will use the solution?What will be the economic benefit of a successful solutionIs there another source for the solution that you need?

7

12-CRS-0106 REVISED 8 FEB 2013RE Task : ElicitationIt certainly simple enough, butWhy difficult :Problem of ScopeThe boundary of the system is ill-definedProblem of UnderstandingThe customer/users are not completely sure of what is neededProblem of volatility The requirement change over timeTo help overcame these problem, requirement engineers ,must approach the requirement gathering activity in an organized manner8

12-CRS-0106 REVISED 8 FEB 2013RE Task : Elicitation (cont.)Elicitation Process Guideline:meetings are conducted and attended by both software engineers and customersrules for preparation and participation are establishedan agenda is suggested a "facilitator" (can be a customer, a developer, or an outsider) controls the meetinga "definition mechanism" (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is usedthe goal is to identify the problempropose elements of the solutionnegotiate different approaches, and specify a preliminary set of solution requirements

9

12-CRS-0106 REVISED 8 FEB 2013Quality Function DeploymentIs a technique that translate the need of the customer into technical requirement for software.QFD emphasize an understanding of what is valuable to the customer and then deploys these values throughout the engineering processQFD identifies three types of requirement :Normal RequirementExpected requirementExciting requirement10

12-CRS-0106 REVISED 8 FEB 2013Elicitation Work Productsa statement of need and feasibility.a bounded statement of scope for the system or product.a list of customers, users, and other stakeholders who participated in requirements elicitation a description of the systems technical environment.a list of requirements (preferably organized by function) and the domain constraints that apply to each.a set of usage scenarios that provide insight into the use of the system or product under different operating conditions.any prototypes developed to better define requirements.11

12-CRS-0106 REVISED 8 FEB 2013RE Task : ElaborationExpand requirement into analysis modelElements of the analysis modelScenario-based elementsFunctionalprocessing narratives for software functionsUse-casedescriptions of the interaction between an actor and the systemClass-based elementsImplied by scenariosBehavioral elementsState diagramFlow-oriented elementsData flow diagram12

12-CRS-0106 REVISED 8 FEB 2013RE Task : Negotiationagree on a deliverable system that is realistic for developers and customersSW team & other project stakeholders negotiate the priority, availability, and cost of each requirementThe Process are :Identify the key stakeholdersThese are the people who will be involved in the negotiationDetermine each of the stakeholders win conditionsWin conditions are not always obviousNegotiateWork toward a set of requirements that lead to win-win

13

12-CRS-0106 REVISED 8 FEB 2013RE Task : SpecificationFinal work product produced by requirement engineer. Can be any one (or more) of the following:A written documentA set of modelsA formal mathematicalA collection of user scenarios (use-cases)A prototype

14

12-CRS-0106 REVISED 8 FEB 2013RE Task : Validationexamine the specification to ensure that SW requirement is not ambiguous, consistent, error free etca review mechanism that looks forerrors in content or interpretationareas where clarification may be requiredmissing informationinconsistencies (a major problem when large products or systems are engineered)conflicting or unrealistic (unachievable) requirements.15

12-CRS-0106 REVISED 8 FEB 2013RE Task : Validation (cont.)A review of the analysis model addresses the following question :Is each requirement consistent with the overall objective for the system/product?Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?Is each requirement bounded and unambiguous?Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? Do any requirements conflict with other requirements?

16

12-CRS-0106 REVISED 8 FEB 2013RE Task : Validation (cont.)Is each requirement achievable in the technical environment that will house the system or product?Is each requirement testable, once implemented?Does the requirements model properly reflect the information, function and behavior of the system to be built.Has the requirements model been partitioned in a way that exposes progressively more detailed information about the system.Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements?

17

12-CRS-0106 REVISED 8 FEB 2013RE Task : Requirement ManagementSet of activities that help the project team identify, control and track requirement and changesUse Traceability table :

18

12-CRS-0106 REVISED 8 FEB 2013Thank You19

12-CRS-0106 REVISED 8 FEB 2013