1 / 67

CSE 4312 Software Engineering Requirements

CSE 4312 Software Engineering Requirements. Instructor: Antonio Oliveira oliveira@cs.yorku.ca Classes: Tuesdays and Thursdays Time : 4:00 – 5:30 PM Room: CB 129. Textbook. Requirements Engineering - Processes and Techniques Gerald Kotonya and Ian Sommerville

salome
Télécharger la présentation

CSE 4312 Software Engineering Requirements

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. CSE 4312Software Engineering Requirements Instructor: Antonio Oliveira oliveira@cs.yorku.ca Classes: Tuesdays and Thursdays Time : 4:00 – 5:30 PM Room: CB 129

  2. Textbook Requirements Engineering - Processes and Techniques Gerald Kotonya and Ian Sommerville Publication info: Chichester ; New York : J. Wiley & Sons, c1998. ISBN: 0471972088

  3. Classes Tuesdays and Thursdays • Time 4:00 – 5:30 PM • Room CB 129 • Mid-term Exam November 3rd • Final Exam To be determined

  4. Scoring Assignments 10 points each (2) Mid-term exam 35 points Final exam 45 points

  5. Assignments Policy Due dates To be specified • Late Assignments Late assignments will face a 15% penalty for each day after due day. Hence, one day later means 85% is your maximum, 2 days means 70% is your maximum and so on. Saturday and Sunday count also. • Assignments later than 3 days will not be accepted and they will receive a mark of zero. Missed assignments No reason: graded with 0 With reason: transferred to final exam value

  6. Directions email oliveira@cs.yorku.ca office TEL Building 3053 Office Hours –Wednesdays and Thursdays 11:00 A.M. – Noon

  7. The Course at a Glance • Introduction • Elicitation • Modelling • Analysis • Management

  8. 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.

  9. System: (Macmillan English Dictionary) System: a set of interrelated components, or sub-systems, with a particular purpose. 1) there are 2 components at least, 2) each of which is related (directly or indirectly) to every other component and, 3) no sub set of which is unrelated to any other subset. Ackoff, Russell L., (1971). Towards a System of Systems Concepts. Management science, 17(11), 661-71. • [count] 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 capital’s inadequate public transportation system

  10. Context • Software crises continues • Denver Airport • More than 50 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

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

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

  13. USA • Requirements Management is seen as one of the most important problems to be overcome in order for companies to achieve level 2 in the SEI’s CMM (Capability Maturity Model) • SEI has recently released a package aiming to transfer technology in RE to facilitate companies’ certification

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

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

  16. Schach’s Summary

  17. 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

  18. 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.

  19. Definition “ 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. This Year will have the 11th edition of this congress. 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.”

  20. 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.”

  21. 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.

  22. 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.”

  23. Brief History • Requriements Engineering as a discipline: 1993 • RE (93, 95, 97, 99. 01) • ICRE (94, 96, 98, 00) • WER (98, 99, 00, 01) • Requirements Engineering Journal • Past : System Analysis • Today : A network of processes • Pressure from the market for quality(CMM e ISO) • Books (Sommerville, Jackson, Loucopoulos, …) • Tools (Doors, Requisite-Pro, Caliber-RM)

  24. 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) McGraw 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

  25. More Books • Exploring Requirements : Quality Before Designby Donald C. Gause and Gerald M. Weinberg (September 1989) Dorset House; ISBN: 0932633137 Amazon.com Sales Rank: 13,641 (disponível em Português) • 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

  26. Links for Information on RE • http://www.er.les.inf.puc-rio.br • http://www.scielo.br/scielo.php?script=sci_abstract&pid=S0104-65001999000200003&lng=en&nrm=iso • http://www.telelogic.com/products/doorsers • http://www.starbase.com/ • http://www.rational.com/products/reqpro/index.jtmpl • http://www.cs.ucl.ac.uk/research/renoir/ • http://www.shu.ac.uk/tfre/ • http://www.re01.org http://www.re02.org • http://link.springer.de/link/service/journals/00766/index.htm

  27. Market • Starbase • http://www.tbi.com/caliberrm30/index.cfm • Telelogic • http://www.er.les.inf.puc-rio.br/doors.htm • Rational • http://www.rational.com/products/reqpro/index.jsp • EDS • http://www.eds.com/products/plm/teamcenter/slate/ • Igatech systems • http://www.igatech.com/rdt/index.html

  28. CSE 4312Software Engineering Requirements Antonio de Padua Albuquerque Oliveira Luiz Marcio Cysneiros Fall 2005

  29. 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

  30. Process improvement • Process improvement is concerned with modifying processes in order to meet some improvement objectives • Improvement objectives • Quality improvement • Schedule reduction • Resource reduction

  31. Planning process improvement • What are the problems with current processes? • What are the improvement goals? • How can process improvement be introduced to achieve these goals? • How should process improvements be controlled and managed?

  32. 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

  33. Process maturity • Process maturity can be thought of as the extent that an organization has defined its processes, actively controls these processes and provides systematic human and computer-based support for them. • The SEI’s Capability Maturity Model is a framework for assessing software process maturity in development organizations

  34. Capability maturity model

  35. Maturity levels • Managed level • Detailed measurements of both process and product quality are collected and used to control the process. • Optimizing level • The organization has a continuous process improvement strategy, based on objective measurements, in place.

  36. RE process maturity model

  37. RE process maturity levels • Initial level • No defined RE process. Suffer from requirements problems such as requirements volatility, unsatisfied stakeholders and high rework costs. Dependent on individual skills and experience. • Repeatable level • Defined standards for requirements documents and policies and procedures for requirements management. • Defined level • Defined RE process based on good practices and techniques. Active process improvement process in place.

  38. Good practice for RE process improvement • RE processes can be improved by the systematic introduction of good requirements engineering practice • Each improvement cycle identifies good practice guidelines and works to introduce them in an organization

  39. Software Development System Establish goals Manage the SDS 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

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

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

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

  43. Problems • Management Support • Availability of Processes • Integration of Platforms • Education vs Ignorance • Cost

  44. The Context of RE • Information System • Engineering Systems • Organizations Producing Software • Models

More Related