ITEC 4040 Requirements Management

1. ITEC 4040Requirements Management Luiz Marcio Cysneiros http://www.yorku.ca/cysneiro/courses.htm Some Slides were Based on presentations from Eric Yu, Alexei Lapouchnian and Steve Easterbrook

2. Textbook Requirements engineering : processes and techniques Gerald Kotonya and Ian Sommerville. Publication info: Chichester ; New York : J. Wiley & Sons, c1998. ISBN: 0471972088

3. Scoring Mid-term exam 45 points Final exam 55 points If you get less than 35% in the Final Exam you Fail the course.

4. Final and Round up • Final = Everything goes on it • No Round up • Ex: 49.8 = E

5. Directions email cysneiro@yorku.ca office TEL Building 3051 Office Hours – Tuesday: 2:00 PM to 3:30 PM and Wednesday 5:00 PM to 6:30 PM

10. The Course at a Glance • Introduction • Elicitation • Modelling • Analysis • Management • Advanced Topics: Goal/Agent-Oriented RE, Social Modelling for RE

11. Course Objectives • Understand the nature of Requirements and Requirements Engineering – skills needed, many foundational disciplines, etc. • Examine standard techniques, notations, methods for requirements • Examine some advanced requirements approaches

12. Recap: Systems Analysis

13. Systems/Requirements Analyst • Person who performs systems analysis • Different possible job titles • Systems analyst • Business systems analyst • Business analyst • Process analyst • Requirements engineer • Requirements analyst • Product owner • Role is evolving • Systems analyst [WB*] • a specialist who studies the problems andneeds of an organization to determine howpeople, data, processes, and informationtechnology can best accomplishimprovements for the business * [WB - Whitten, J. L., Bentley, L. D. Systems Analysis and Design Methods,7th edition, Irwin McGraw-Hill, 2007] * [WB - Whitten, J. L., Bentley, L. D. Systems Analysis and Design Methods,7th edition, Irwin McGraw-Hill, 2007]

14. Skills for a Systems Analyst • Problem solving • Business acumen • Domain expertise • IT knowledge (IS, various technologies, programming) • Communication • Dealing with business and technical (IT) people • Interviewing, meeting facilitation, etc. • Liaison b/w business and IT

16. What is a System? • A system is a group of interrelated components that function together to achieve a desired result [WB] • System [Alter] • Social – no significant use of technology • Sociotechnical – human participants make use of technology • Automated – fully automated once triggered by people, events, etc. • An information system (IS) is an arrangement of people, data, processes, and information technology that interact to collect, process, store, and provide as output the information needed to support an organization [WB]

17. More System Definitions • Macmillan English Dictionary • A set of connected things that work together for a particular purpose • A central heating system • I decided to install a security system to prevent any break-ins. • The city’s inadequate public transportation system

18. More System Definitions • Weinberg [Gerald M. Weinberg. Introduction to General Systems Thinking, 1975] • “A system is a way of looking at the world” • Systems don’t really exist! • Just a convenient way to describe things (e.g., just like “sets”)

19. Nowadays World • Software-Intensive Systems • Software vs Systems ? • Software Alone is useless • Hardware Alone is useless • Both only exist when used to support any human activity • Software+Hardware+People+activities • Systems • Intensive use of software systems

20. Nowadays World • Software systems present opportunities for change • It may be complex but should also be adaptable • Changes very quickly and some times very frequently • A New System may change human activities in many significant ways • Paperless Hospitals • Virtual Doctors • Virtual Surgeries • Phone Chat • facebook

21. Nowadays World • Software Systems became Ubiquitous • Even Refrigerators have software systems today • However, we are frequently disappointed with them

22. Quality = Fitness for Purpose • Software is designed for a purpose • If it doesn’t work well, then either: • The designer didn’t have an adequate understanding of the purpose • Or it is used for a purpose different from the intended one • Requirements engineering is about identifying this purpose • Inadequate understanding of the purpose leads to poor quality software • Poor requirements practices → poor quality software

23. Requirement: (Macmillan English Dictionary) • something that is needed in order for something to happen: • Check the car’s fuel requirements. • Good insulation can cut the energy requirements of a house by more than half. • something that a rule, law, contract, etc. states that you must do: • Do these goods comply with our safety requirements? • requirement of: It is usually a requirement of banks and investors that a new company is formed to effect the management buy-out. • requirement for: Applicants must satisfy the requirements for admission to the university.

24. Req. Engineering Job ? Denys Lasdun – “Our job is to give the client, on time and on cost, not what he wants, but what he never dreamed he wanted; and when he gets it, he recognizes it as something he wanted all the time”

25. Context • Software crises continues • Denver Airport • More than 560 millionUS $ due to errors in the baggage control system • London Ambulance Service • The system was deactivated one day after its deployment due to many errors. Most of them related to non-functional requirements such as: Safety, Reliability and Usability

26. High costs Unhappy Clients Software Crises • Flaws in the Production Process

27. Europe • Questionnaire sent to 3.805 companies showed: • For the Analysts, Major problems are: • Requirements specification (53%) • Requirements Management (43%) • Documentation (36%) • Test (35%)

28. “26% of the Software projects were considered a success.” Standish Group, CHAOS Report, 2000 Good News …

29. Meaning that 74% have FAILED! Standish Group, CHAOS Report, 2000 Bad News…

30. Even Worse: • CHAOS Report, 2015. The Standish Group. • “29% of the Software projects were considered a success.” • Almost two-fold increase from 1994! • But this means that 71% were not (fully) successful!

31. CHAOS Reports • Widely cited (since 1994) • Type 1. Project success: completed on-time and on-budget, with all features and functions as initially specified • Type 2. Project challenged: completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified • Type 3. Project impaired: project is canceled at some point during the development cycle

32. From the CHAOS Reports

33. From the CHAOS Reports

34. From the CHAOS Reports

35. Tom De Marco “56% of the errors in a software can be traced back to the requirements phase” • The later an error is detected the more expensive is to fix it. • Many errors are done during Requirements elicitation and analysis

36. Many errors in requirements can (and should) be detected early in the software development life cycle. • Typical errors include: Use of incorrect facts, omission, inconsistency and ambiguity. • Errors in requirements specification are one of the major concerns for software industry.

37. 200 x Cost to Repair Analysis Design Code Unit Test Integration Test Maintenance Stage when the Error is found

38. Definition of RE “ Requirements engineering is a sub-area of Software Engineering that studies the process of defining the requirements for a software-to-be. It is a new area started in 1993 when the 1st International Symposium on RE was organized. The process for defining requirements is an interface between the desires and the needs of the clients and a future implementation of these requirements as a software.”

39. Another Definition • RE is: “The development and use of technology effective to elicit, specify and analyse requirements from stakeholders (clients/users) that shall be performed by a software system.”

43. Goals • Understand the needs and support the client’s desires. • Provide the Software Engineer with methods, techniques and tools to help on the process of understanding and registering what a software must do.

44. Fred Brook’s • Brook adds: “The most difficult part of building a software system is to decide, precisely, what must be built. No other part of the work can undermine so badly the resulting software if not done correctly. No other part is so difficult to fix later.”

45. Factors influencing requirements • Personality and status of stakeholders • The personal goals of individuals within an organization • The degree of political influence of stakeholders within an organization

46. RE process problems • Lack of stakeholder involvement • Business needs not considered • Lack of requirements management • Lack of defined responsibilities • Stakeholder communication problems • Over-long schedules and poor quality requirements documents • Many confuse it with Design • Pressure from the Market • “It has to be ready next week” • Clients keep adding and changing things

47. Software Development System Establish goals Manage the SDS/SDLC MANAGEMENT Produce software Build a team Create systems PEOPLE give feedback Support creative work METHODS Implement policies Keep the state of the art organize systems INFORMATION support methods process information TOOLS Guarantee policies are followed reuse information Measure the process record software

48. Most Common Scenario • Structured Analisys • Structured Project • Entity-Relationship Model • Essential Analysis • Objects • CASE • Automatic Genaration of Applications

49. Abstraction X Formalism Abstract Very High Level Ideal Conventional Concrete/Abstract High Level Low Level Goal MachineLevel Concrete Talk Specification Code Informal Linguistic Level Formal

50. Why Requirements Engineering? Von Neumann: “There is no sense in being precise when you don’t even know what you are talking about”