ITEC 4040 Requirements Management Luiz Marcio Cysneiros Some
- Slides: 65
ITEC 4040 Requirements Management Luiz Marcio Cysneiros Some Slides were Based on presentations from Eric Yu, Alexei Lapouchnian and Steve Easterbrook 1
Textbook Requirements engineering : processes and techniques Gerald Kotonya and Ian Sommerville. Publication info: Chichester ; New York : J. Wiley & Sons, c 1998. ISBN: 0471972088 2
Scoring Final exam 100 points 3
Directions email office cysneiro@yorku. ca TEL Building 3051 Office Hours – Tuesday 2: 30 PM to 3: 30 PM 4
5
6
7
8
The Course at a Glance • • • Introduction Elicitation Modelling Analysis Management Advanced Topics: Goal/Agent-Oriented RE, Social Modelling for RE 9
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 10 10
Recap: Systems Analysis 11
Systems/Requirements Analyst • Person who performs systems analysis • Different possible job titles – – – – Systems analyst [WB*] Systems analyst • a specialist who studies the problems and needs of an organization to determine how Business systems analyst people, data, processes, and information Business analyst technology can best accomplish improvements for the business Process analyst Requirements engineer Requirements analyst * [WB - Whitten, J. L. , Bentley, L. D. Systems Analysis and Product owner Design Methods, 7 th edition, Irwin Mc. Graw-Hill, 2007] • Role is evolving * [WB - Whitten, J. L. , Bentley, L. D. Systems Analysis and Design Methods, 7 th edition, Irwin 12 Mc. Graw-Hill, 2007] 12
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 13 13
14
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] 15 15
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 16 16
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”) 17 17
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 18
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 19
Nowadays World • Software Systems became Ubiquitous – Even Refrigerators have software systems today – However, we are frequently disappointed with them 20
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 21 21
Requirement: (Macmillan English Dictionary) something that is needed in order for something to happen: 1. – Check the car’s fuel requirements. – Good insulation can cut the energy requirements of a house by more than half. 2. 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. 22
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” 23
Context • Software crises continues – Denver Airport • More than 560 million US $ 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 24
Software Crises • Flaws in the Production Process Unhappy Clients High costs 25
Europe • Questionnaire sent to 3. 805 companies showed: • For the Analysts, Major problems are: – Requirements specification (53%) – Requirements Management (43%) – Documentation (36%) – Test (35%) 26
Good News … “ 26% of the Software projects were considered a success. ” Standish Group, CHAOS Report, 2000 27
Bad News… Meaning that 74% have FAILED! Standish Group, CHAOS Report, 2000 28
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! 29
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 overbudget, 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 30 30
From the CHAOS Reports 31 31
From the CHAOS Reports 32 32
From the CHAOS Reports 33 33
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 34
• 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. 35
200 x Cost to Repair Analysis Design Code Unit Test Integration Maintenance Test Stage when the Error is found 36
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 1 st 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. ” 37
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. ” 38
39
40
41
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. 42
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. ” 43
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 44
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 45
Software Development System Establish goals MANAGEMENT give feedback Manage the SDS/SDLC Build a team Produce software Create systems PEOPLE Support creative work Implement policies METHODS Keep the state of the art support methods INFORMATION reuse information Guarantee policies are followed organize systems process information TOOLS Measure the process record software 46
Most Common Scenario • • Structured Analisys Structured Project Entity-Relationship Model Essential Analysis Objects CASE Automatic Genaration of Applications 47
Abstraction X Formalism Abstract Very High Level Ideal Concrete/Abstract Conventional High Level Low Level Goal Talk Informal Specification Linguistic Level Code Machine Level Concrete Formal 48
Why Requirements Engineering? Von Neumann: “There is no sense in being precise when you don’t even know what you are talking about” 49
Context • The Blank Page Fallacy • The Completeness Fallacy • Social Aspects Involved 50
So, What are Requirements? Clients Users Needs Limitations Impossibilities Technological Infra-Structure 51
Definition • Software Requirements – Sentences that express clients’ needs and establish the desired quality 52
Types of Requirements • Functional Requirements – FR are the requirements that are directly related to the software functionality. – What the system must do ! • Non-Functional Requirements – NFRs express constraints that a software must comply with. – Can be seen as specific qualities that a software must have – “How” the software must do the “What” • Ex: Safety, accuracy, usability, security • Requirements-1 (Inverse Requirements) – IR establish conditions that must never happen – Frequently associated to an NFR 53
After all, What are Requirement? Clients FR Users Needs Limitations Impossibilities NFR IR Technological Infra-Structure 54
Definitions • Requirement – Necessary condition to achieve a certain goal, or the fulfillment of a certain goal • Specification – Detailed description of the characteristic that a material, work, or service must present 55
Examples • The system should provide a form to enter results for clinical tests performed for a client (FR) • Depending on the result of the test, only the Supervisor can entry the result for this patient. E. g. Glucose over 8. 0 (NFR Safety) • The system should give the client a receipt. This should take no longer than 8 sec (FR “. ” NFR Performance) • The system can not erase any client information (IN) 56
Definitions • Universe of Discourse – Is the context in which the software should be developed and operated. Uof. D includes all sources of information and all people related to the software. These people are also known as the actors of this universe. Uof. D is a reality circumstantiated by the set of goals defined by those who demand the software 57
Information Systems Universe of Discourse Macrosystem Software System 58
organization hardware software Information System 59
The “Requirements Lifecycle” • • Not Waterfall Not Spiral Not Iterative Elicitation, Modelling and Analysis are activities not phases ! 60
An SADT Model for the Definition of Requirements Uof. D Select Personel Uof. D Soft. Eng. Viewpoints clients Elicit method facts requirements Model model Uof. D Select Method Analyse tools Management 61
62
Books • Requirements Engineering: Processes and Techniques by Ian Sommerville, Gerald Kotonya (September 1998) John Wiley & Son Ltd; ISBN: 0471972088 Amazon. com Sales Rank: 188, 502 • System Requirements Engineering by Pericles Loucopoulos, Vassilios Karakostas (June 1995) Mc. Graw Hill Text; ISBN: 0077078438 Amazon. com Sales Rank: 1, 067, 908 • Software Requirements & Specifications : A Lexicon of Practice, Principles and Prejudices by Michael Jackson (July 1995) Addison-Wesley Pub Co; ISBN: 0201877120 Amazon. com Sales Rank: 38, 607 63
More Books • Exploring Requirements : Quality Before Design by Donald C. Gause and Gerald M. Weinberg (September 1989) Dorset House; ISBN: 0932633137 Amazon. com Sales Rank: 13, 641 • Mastering the Requirements Process by Suzanne Robertson, James Robertson (May 4, 2000) Addison-Wesley Pub Co; ISBN: 0201360462 ; Dimensions (in inches): 0. 93 x 9. 50 x 7. 66 Amazon. com Sales Rank: 7, 392 • Managing Software Requirements: A Unified Approach (The Addison. Wesley Object Technology Series)by Dean Leffingwell, Don Widrig (November 1999), Addison-Wesley Pub Co; ISBN: 0201615932 Dimensions (in Inches): 1. 13 x 9. 46 x 7. 76 Amazon. com Sales Rank: 14, 447 64
Reading for next Class • Requirements Engineering - a roadmap - Nuseibeh, Easterbrook • [Goguen 94] - Goguen, J. A. and Linde, C. - Techiques for Requirements Elicitation, In Proceedings of the First IEEE International Symposium on Requirements Engineering, San Diego, Ca, IEEE Computer Society Press - 1994, pp 152 -164. • [Goguen 94 a] - Goguen, Joseph - Requirements Engineering as the reconciliation of social and technical issues - in Requirements Engineering: Social and Technical Issues edited by Joseph Goguen and Marina Jirotka - Academic Press 1994. • Download from course page 65
- Luiz marcio cysneiros
- Harvard concur
- Qhy411
- Smf 4040
- Qhy 4040
- Qhy 4040
- Marcio janot
- Fundo ostia marcio
- Marcio rodas
- V=512cm3
- Marcio rodas
- Marcio rodas
- Márcio bilharinho naves
- Projet itec
- Ad systems exam slide
- Itec 4010
- Itec 3220
- Gestin itec
- Itec 3220
- Itec 3220
- Itec 1000
- Itec 1000
- Itec 1000
- Itec 1000
- Itec 1000
- Itec 1010
- Itec exam results
- First cut diagram
- Dot pitch
- Itec irrigation controller
- Itec 350
- Itec
- Itec
- Cs itec
- Itec
- Edmodo основатели
- Qu es
- Itec software
- They say it only takes a little faith
- Sometimes you win some sometimes you lose some
- Is cake countable or uncountable
- Contact forces
- Some say the world will end in fire some say in ice
- Some say the world will end in fire some say in ice
- Some may trust in horses
- "artigo"
- Luiz carlos de castro
- Antônio luiz seabra
- Assum preto luiz gonzaga
- Etapas de um trabalho de pesquisa
- Luiz vicente de souza queiroz
- Luiz felipe em japonês
- Rodrigo aranha
- Celk navegantes
- Desenho de pedro luiz padovini
- Marcos luiz mucheroni
- Luiz pareto
- Marcos luiz mucheroni
- Marcos luiz mucheroni
- Marcos luiz mucheroni
- Bussunda luiz guilherme vianna
- Músicas de luiz gonzaga
- Washington luiz ferreira rios
- Luiz felipe ramos
- Jeito barsi de investir
- Pedro luiz de castro