Lecture 08

1. Lecture 08 ITEC 4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

2. Analysis Analysis do Carry out use Carry out Validation use use Identify the parts People Verification depends on Tools Methods Points of View ITEC 4040 – Requirements Management

3. Verification vs. Validation • Verification • Are we building the thing right? • Compared to other products  Among Models • Validation • Are we building the thing right? • Regarding stakeholders/users desires  Between the UofD and a Model ITEC 4040 – Requirements Management

4. Analysis • Identify the parts • How is it organized? • How is it stored? • Traceability • Verification • Formal • Reuse domains • Inspections • Validation • Close to the user/stakeholders • Informal • Prototyping (mock up, storyboard) ITEC 4040 – Requirements Management

5. Analysis Loop ITEC 4040 – Requirements Management

6. Identification of the Parts • Depends on how the models are organized and stored • Linked to modelling and elicitation • Majority of problems can be traced down to requirements ITEC 4040 – Requirements Management

7. Validation • Are we building the right product? • We have to compare the UofD with ussers/stakeholders expectations • Run scenarios (reading them in meetings) • Prototype ITEC 4040 – Requirements Management

8. Validation Strategies • Informal corroboration • Storyboards • Prototypes ITEC 4040 – Requirements Management

9. Validating through Scenarios • As many times as possible • The earlier the better • If possible, validate the candidate scenario list • Scenario validation goal: elaborate the Discrepancies, Errors and Omissions (DEO) List • Users’ commitment is essential • Gradual confirmation of scenarios parts (objective, actors, resources) • Feedback for LEL • Tag scenarios where doubts arise • Make notes of discrepancies, errors or omissions ITEC 4040 – Requirements Management

10. Validating through Scenarios • Validate using users in semi-structured interviews • Strategies: • Read scenarios aloud together with users • Ask if they have anything to add or change • Ask why often! ITEC 4040 – Requirements Management

11. Storyboard • Elicit reaction such as “Yes, but…” • Passive, active or iterative • Identify actors, explain what happens to them and describe how it happens • More effective to projects with innovative or unknown context • Pros: • Cheap • User friendly, informal and iterative • Allows for criticism of various aspects of a system early in the project • Easy to create and modify ITEC 4040 – Requirements Management

12. Storyboard • Types: • Passive • Static screens • Business rules • Reports • Active • Presentation (as in PowerPoint) • Animation • Simulation • Iterative • Demo (free browsing) • Interactive presentation ITEC 4040 – Requirements Management

13. Prototype • Prototypes are partial implementation to help stakeholders, users and developers to better understand system requirements • Also helps to elicit reactions such as “Yes, but…” • Helps to clarify fuzzy requirements • Requirements that are known but not well defined or not well understood • Help elicit reactions such as “Now that I can see it working, it comes to me that I also need…” • Availability of tools that help to build fast and cheap prototypes ITEC 4040 – Requirements Management

14. Prototype • Types • Throw away • It has to work • Use any means to implement the desired result (it does not care for quality code) • Once the requirements are elicited the prototype is deleted • Evolving • Implemented using the same architecture being used in the system • The system may be an evolution of this prototype ITEC 4040 – Requirements Management

15. Prototype • Vertical vs. Horizontal • Horizontal • Implements a large portion of the functionality • Vertical • Implement a few functions • Better quality ITEC 4040 – Requirements Management

16. Verification • Are we building the product correctly? • Use of models • Representations/languages • Use of formalisms  Formal proofing of a model • Theorem proofing • Detection of discrepancies between the model and the meta models Model proofing • Informal techniques ITEC 4040 – Requirements Management

17. Verification Techniques • Inspection • A formal evaluation technique in which artifacts are examined in detail by a person or group other than the author to detect errors, violations of development standards, and other problems. Formal, initiated by the project team, planned, author is not the presenter. • Walkthrough • A review process in which a developer leads one or more members of the development team through a segment of an artifact that he or she has written while the other members ask questions and make comments about technique, style, possible error, violation of development standards, and other problems. Semi-formal, initiated by the author, quite frequently poorly planned. ITEC 4040 – Requirements Management

18. Verification Techniques – Walkthrough • Ad-hoc preparation • Meeting (Authors, evaluators, secretary) • Reading • Author reads • Evaluators hear • Evaluators point out problems (questions) • Secretaries write down problems • List of problems ITEC 4040 – Requirements Management

19. Verification Techniques – Inspections • Created in 1972 by Fagan at IBM to improve quality of code • Currently, they are used to check any type of artifact used in the software development process • Inspection can detect between 30% - 90% of existing errors • Reading techniques applied to an artifact aiming at detecting errors in the artifact according to pre-established criteria • Formal • Initiated by the project team leader • Planned meetings with fixed roles assigned to all the members involved • Reader reads the product code. Everyone inspects it and comes up with defects • Secretary records the defects • Moderator has a role in making sure that the discussions proceed on productive lines ITEC 4040 – Requirements Management

20. Inspections in Requirements • Based on check lists: • Inspectors use a list with items to be checked • Each artifact has a specific list (requirements document, use cases, lexicon, scenario, DFD, class diagram, etc.) • Defects are annotated in the artifact being analyzed • After reviewing, a meeting is carried out to communicate the problems found to developers • Defects that can be found: • Incorrect syntax in the artifacts • Inconsistent information among artifacts • NFRs not explicated • Actors or resources incomplete or in excess • No pre-conditions (use case and scenarios) • No exceptions in scenarios ITEC 4040 – Requirements Management

21. DFD • Checklist DFD • The documentation should contain: • Date, numbered pages, list of topics, change and version control • Process represented by a numbered circle • Identifier should begin with a verb • Maximum number of processes should be 7±2 ITEC 4040 – Requirements Management

22. Object Orientation • Checklist OO: • Are all classes represented using rectangles with 1, 2, or 3 compartents? • Are there two classes with the same name? • Are there classes without defined relationships? • Are the attributes and methods for each class adequate? • Do all the use cases have corresponding sequence diagrams? • Coupling and cohesion are adequate? ITEC 4040 – Requirements Management

23. N-Fold Inspection • May teams • Each one carries out an independent inspection process • Compare results • Final report • Parallel is better • Multiple inspection teams find more defects than one single bigger team • The teams tend to find subsets of different defects • The combination of the various results from the different teams tends to sum instead of being redundant • Follow up • Release the document • Owner and moderator ITEC 4040 – Requirements Management

24. Challenges from Inspections • Big Requirements Document • Informal and incremental revisions during the development of specification • Each inspector starts from a different point • Divide into many small teams – each team inspects a specific part of the document • Large inspections: • Difficult to schedule meetings • Parallel conversation • Difficult to get an agreement • Understand which point of view the inspector is using and keep only one to each interested part • Establish many small teams and carry out the inspection in parallel. Combine the lists and remove redundancies ITEC 4040 – Requirements Management

25. Challenges from Inspections • Geographical distance between inspectors • Videoconference, teleconference, email, web • Difficult to observe corporal language and expressions • Difficult to moderate • 25% reduction on the effectiveness [Wiegers ’98] ITEC 4040 – Requirements Management

26. Requirements Management ITEC 4040 – Requirements Management

27. Configuration Management • Change control • Advantages • Avoid potentially destructive or frivol changes on requirements • Keep/maintain updated revisions of requirements documentation • Facilitate the recovery and reconstruction of previous versions • Offer support to a configuration strategy for new versions • Prevent simultaneous changes ITEC 4040 – Requirements Management

28. Configuration Management • Version control • Coordinate and manage objects in evolution • Successive refinements • Requirements • Models • Code • Keep intermediary versions • Log of changes • Access to different configurations ITEC 4040 – Requirements Management

29. Management • Scope • Changes • Risk • Traceability • Prioritization ITEC 4040 – Requirements Management

30. Requirement Management • Managing requirements is to ensure all clients requests are being examined during the SDLC • For this, it is essential that such requests are related to software products (requirements allocation) • It is orthogonal to the process of requirements definition (elicitation, modelling and analysis) • Supervise the whole process of software development and evolution ITEC 4040 – Requirements Management

31. About Scope • What is scope? Combination of functionality, resources and time • Problems • NFR: May consume a big portion of time and resources • Not all resources are available or are known at the beginning • Typical culture that software is always LATE • Time – saving time is an illusion • Adding people to a late project will only make this project worse - Brooks ITEC 4040 – Requirements Management

32. Controlling the Scope • “Since” syndrome – keep adding requirements • Caper Jones reports that requirements that “crawl under the scope” represent • Risk of 80% to information system projects • Risk of 70% to military projects • Crawling requirements • New functionality • Modifications • Requirements • Bigger scope • Say no ITEC 4040 – Requirements Management

33. What it Means to Prioritize? [Wiegers] • Trade offs between: • Scope • Time • Resources • Assure that the Essential is done • Why prioritize? • High expectations • Short time • Limited resources • Saying: “We do what we can not what we want” ITEC 4040 – Requirements Management

34. Prioritization Techniques • We are regularly confronted with high impact decisionsthat require prioritizing often competing requirements • A formal technique known as Quality Function Deployment was developed to tackle this problem with the ultimate goal of translating subjective quality criteria into objective ones that can be quantified and measured • 3 main goals: • Prioritize spoken and unspoken requirements • Translate requirements into technical characteristics and specifications • Build and deliver a quality product or service ITEC 4040 – Requirements Management

35. Prioritization Techniques • Formal • Quality Function Deployment (QFD) • Participants: Manager, Key figures, Developers • Steps in the process: • List in a spreadsheet the requirements, functionality or use cases that you want to prioritize • Estimate the relative benefit of each one using a 1-9 scale, where 1 means something that is not important and a 9 a great value requirement • Estimate the penalty the client or the business will suffer if the requirements is not included. 1 means a minimum penalty while 9 means a huge loss • Create a column – total value – which represents the sum of the benefit and penalty • Use a spreadsheet to calculate the percentage of the total value that each item represents (value%) ITEC 4040 – Requirements Management

36. Prioritization Techniques • Formal • QFD • Participants: Manager, Key figures, Developers • Steps in the process: • Estimate the implementation cost for each item also using a 1(low) to 9(high) scale • Use the spreadsheet to calculate the percentage of the total cost each item represents (cost%) • Estimate the risk each item represents using a 1 to 9 scale • Use the spreadsheet to calculate the percentage of the total risk that each item represents (risk%) ITEC 4040 – Requirements Management

37. Prioritization Techniques • Formal • QFD • Once we have all the estimative: • Organize the item using a descending order in priority ITEC 4040 – Requirements Management

38. Prioritization Techniques • Formal • QFD • Critics: • Semi-quantitative method • Not very precise • Depends on personal skills. How well one can estimate benefits, cost and risk ITEC 4040 – Requirements Management

39. Prioritization Techniques • Informal Techniques [Leffingwell] • $100 • Carried out during a meeting • Each participant is given $100 to spend buying requirements • Write in a piece of paper how much money you would spend in each requirement • Tabulate results • Requirements ranking ITEC 4040 – Requirements Management

40. Prioritization Techniques • Informal Techniques • Categorization • Offline • Each interested part gets a list of requirements • Classify according to the following criteria • Critical – indispensable • Important – represents loss of functionality or loss off market share • Useful – makes life easier • Set values 1, 2 or 3 (where 1 is critical) • Make a ranking with the results ITEC 4040 – Requirements Management

41. Risk Management • Occurrences that may impact the project • Combination of probability and type of consequence • Processes: • Identification • Weighing • Planning • Control ITEC 4040 – Requirements Management

42. Identifying Risks • Conditions, activities, decisions that may affect the success of the project • Types of risk • Scope (larger/smaller) • Evolution • Resources • Personal (outsourced, partners, employees) • New technologies • NFR (very tight (rigid) constraints) ITEC 4040 – Requirements Management

43. Identifying Risks • Risk levels • Intolerable • Acceptable if reduction is out of question • Acceptable • Negotiable ITEC 4040 – Requirements Management

44. Weighing Risks • Probability • Low • Very low • High • Very high • Risk list sorted by probability • Risk list sorted by level of risk, type and probability ITEC 4040 – Requirements Management

45. Planning • Detecting the sooner the possible from top of the list (level, probability) • Alternatives for correction • Alternatives to live with ITEC 4040 – Requirements Management

46. Control • Verification points between the global plan and the risk list • Responsibilities • Action (following alternatives) ITEC 4040 – Requirements Management

47. Link Requirements to Software Components • Also called traceability, because it must allow one to browse through software products, including the requirements, regarding clients demands ITEC 4040 – Requirements Management

48. Requirements Traceability • Definition: • Ability to follow the life of a requirements • Pre e pos traceability • Implicit and explicit • Internal (to the artifact) and external ITEC 4040 – Requirements Management

49. Pre e Pos Traceability • Pre traceability • Before adding to the requirements document • Where it comes from? • Who suggested? • Why? • Pos traceability • After something is added to the requirements document ITEC 4040 – Requirements Management

50. Pre e Pos Traceability ITEC 4040 – Requirements Management