Requirements Engineering Activities

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)