1 / 19

Requirements Engineering Activities

Requirements Engineering Activities. Elicitation. Analysis & Negotiation. “Formal” Documentation. Requirements “Draft” Doc. continuous documentation. Validation. Validated Requirements Document. Approved “Baseline” Document. represents control flow between major activities .

courtney
Download Presentation

Requirements Engineering Activities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements Engineering Activities Elicitation Analysis & Negotiation “Formal” Documentation Requirements “Draft” Doc. continuous documentation Validation Validated Requirements Document Approved “Baseline” Document represents control flow between major activities represents major information/document flow

  2. Requirements “Validation” loop with users & customers loop with users & customers & other stake holders Elicitation Analysis & Negotiation “Formal” Documentation Requirements “Draft” Doc. continuous documentation Validation Validated Requirements Document Approved “Baseline” Document represents control flow between major activities represents major information/document flow

  3. Requirements Validation • The aim here is to check and certify that the requirements represent the system that is to be implemented. It differs from the requirements analysis step and/or negotiation step: • Analysis and Negotiations focus on ensuring that the requirements are correctly understood and reflect the needs of the stakeholders, rather than the details of correct articulation of the requirements. • Concerned with the “raw” requirements gathered from the stakeholders. • Validation focuses on the documented requirements and how they are represented. • Concerned with checking the document that has already gone throughanalysis and negotiation. • Analysis & Negotiation focus on “have we got the right requirements?” • Validation focuses on “have we represented (got) the requirements • right (correctly)?”

  4. Inputs: Requirements “draft document: should be finished draft User Organization Standard Industry and Regulatory Standards User Organizational & Business Knowledge Requirements prototype Outputs: List of problems to be resolved List of agreed to actions Inputs and Outputs of Requirement Validation Some “typical” problems: - conformance to stds - ambiguous wording - error in the actual model - undetected conflicts Requirements Validation How long does this take? The difficulty in validation lies in comparing the draft document to - - - (what)? So requirements validation asks 2 questions: (1) requirements correctly represented ?; (2) requirements clear enough for others to use ?

  5. Requirements Validation’s Major Questions • Is the Requirements Document Complete? • Is the Requirements Document Consistent? • Is the Requirements Document Accurate?

  6. Some Requirements Validation Techniques • Requirements Reviews (Formal Inspection) • Requirements Prototyping (a more complete one then Elicitation/Analysis/Negotiation time) • Requirements Model Validation • Requirements Testing (Test Case Development)

  7. Requirements Document Review Process Plan Review Distribute Draft Doc. Prepare for Review Follow-up & Re-review needed ? no Conduct Review Get updated doc yes Get ‘Revised’ Req. Doc. Process Based On Type Of Problem Accept ? No Yes, accept Baseline Req. Doc.

  8. Requirements Review (Inspection Process) • Plan the Review (with a moderator): • Selection of review team members • Selection of time and place • Gain agreement on problem definition and problem severity code • * Determine the condition or criteria for “acceptance” or “rejection/re-review” of the document * • Distribution of the “Draft” Requirements Document and any other information • Review Preparation • Review team members read the document for problems • Record down questions and suspected problem areas • **** Hold the Review “meeting” **** • Discuss the discovered problems (HOW DO YOU DO THIS?) • Agree on the 1) severity of the problems and 2) action plan to resolve the problems • Moderator (review chair) follows up to ensure that the action plan items have been carried out • The revised Requirements Document is either accepted or a re-review is conducted; a re-review just follow the above steps again.

  9. Some Planning Considerations • Scheduling • Depends on how much is in the “draft” document • Approximately 15-20 pages/hour of document (depends on how well the draft is written) may be read as review preparation • Approximately 20 – 30 pages may be covered during the actual review meeting (1 hr) (depends on the number and type of problems found) • Moderator (review chairperson) needs to be someone with experience and authority • Pre-Review check for standards, content completeness, consistency, clarity, obvious spelling, etc. may be performed • Review team members: • End-users/customers (e.g. involved during elicitation) • Down stream developers: designers, coders, testers • Domain experts: industry, application, sales, support

  10. Sample Checklist for Review/Inspection • Each organization should establish their own check list • A sample includes: • Understandability • Redundancy • Completeness : this takes a little effort to find • Ambiguity : may also be viewed as “understandability” • Consistency : no contradiction • Organization : document structured sensibly • Conformance to standards : must have knowledge of standards • Traceability : clear linkages to requestor and other requirements Anything you would include or delete from this list? --- e.g. priority

  11. 6-Dimensions of Requirements Business Workflow Individual Functionality Data and Data formats Requirements Existing & Systems Interfaces Other Constraints: Performance, Reliability, etc. User Interfaces These 6 groups of requirements may be used as a prompter for completeness check

  12. Documented Review Results • At the completion of the review there should be a list of problem discovered - for each problem: • A short description of the problem with problem type code • Person who discovered the problem • Problem severity code • Person responsible for the fix (if document is multiple authored) • Recommendation, if any • Estimated fix time frame You may devise a review results “form” from this list Some moderators prepare this “form” ahead of time.

  13. Sample Generic Types of Requirements Problems • Missing information – completeness • Unclear and ambiguous statements – accuracy • Conflicting statements – consistency • Difficult to implement or unrealistic statements (needs versus desires)

  14. Requirements Prototype for Validation • Extend the prototype built earlier for elicitation and analysis. • It may not be worthwhile to build a prototype just for validation purpose • The requirements validation with prototype includes: • Selecting the reviewers of the prototype • Developing “test” scenarios to systematically review the requirements (may need testers help) • “Execute” the developed scenarios • Document the discovered problems • Follow-up to ensure the problems are fixed Extensive work Make sure that there is no confusion between requirements problem and prototype system/programmingproblem

  15. Requirements Model Validation • Different Models, using different techniques, may have been constructed to depict the requirements: • Data Flow • Use Case (OO) • State Transition • Formal (Z Language) • etc • These models need to be validated for • Self consistency and completeness • Cross-model consistency • Accuracy in reflecting requirements

  16. A Requirements Model Validation Method • Paraphrase the model in natural language and have other stakeholders review the paraphrased statements. • A possible template for paraphrasing of a functional requirements includes: • A name for the functionality • Inputs • Transformation/functionality • Outputs • Any special control Many times errors are detected by the modeler himself/herself just in the process of paraphrasing.

  17. Requirements Validation via Test Case Generation • Each requirement must be “testable” – a test case may be designed and executed to demonstrate whether the requirement is attained or not • Actual execution of test is not performed until implementation is complete. • Designing of the test case is a validation method for the requirement – consistency, clarity, may becompleteness These test cases are for what’s called “black box” testing

  18. Each test case should include the following information: Test Case Record Related Requirements Test Description Expected Result Requirement # Status Test Case # 7 # 4 #3 and #12 -ensure that continue not customer address if address reviewed is acceptable accepted (-ensure that “unacceptable” address is not) else error log record is written This is a “general” description --- the test description section will have to be expanded for testers.

  19. Reviewing the Test Cases • Designing the Test Cases serves as a review of the requirement statements • Reviewing the developed test cases further serve as a review of the test case and the requirements statements • Completeness (are all the requirements covered) • Clarity (can we specify the expected results) • Consistency (is there any conflicting result)

More Related