1 / 47

Lecture 01

Lecture 01. Chapter 1 – Introduction Chapter 2 – Requirements Engineering Processes. ITEC 4040 – Requirements Management Prof. Dawid Kasperowicz http://www.yorku.ca/dkasper. Overview. What is a requirement What is a system Overview of requirements and their importance

atalo
Download Presentation

Lecture 01

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. Lecture 01 Chapter 1 – Introduction Chapter 2 – Requirements Engineering Processes ITEC4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

  2. Overview • What is a requirement • What is a system • Overview of requirements and their importance • Types of requirements • Requirements engineering • Requirements engineering process improvement • The Universe of Discourse • Requirement Documents ITEC4040 – Requirements Management

  3. Introduction • Development of computer-based systems will always have problems • Late delivery, over budget, don’t do what users really want and need • Rarely is there a single reason or solution for these problems • One thing we do know is that a major contributory factor for the problems is due to difficulties with the system requirements ITEC4040 – Requirements Management

  4. Requirements Overview ITEC4040 – Requirements Management

  5. In Today’s World • Software-Intensive Systems • Software vs Systems? • Software alone is useless • Hardware alone is useless (exceptions) • Both only exist when used to support any human activity • Software + Hardware + People + Activities • Systems • Intensive use of software systems ITEC4040 – Requirements Management

  6. In Today’s World • Software systems present opportunities for change • It may be complex but should also be adaptable • Changes very quickly and sometimes very frequently • A new system may change human activities in many significant ways • Paperless hospitals • Virtual doctors • Virtual surgeries • Phone chat • Facebook ITEC4040 – Requirements Management

  7. In Today’s World • Software systems became ubiquitous • Even refrigerators have software systems today • However, we are frequently disappointed with them • If it doesn’t work chances are: • Who designed it didn’t understand what was actually needed of the system • It is been used for different purposes than the original intended purpose ITEC4040 – Requirements Management

  8. What is a Requirement? • Definitions • 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 ITEC4040 – Requirements Management

  9. What is a System? • Definitions • A set of connected things that work together for a particular purpose: • A central heating system • Security system • Toronto’s inadequate public transportation system • Some part of a reality that can be observed to interact with its environment • A set of interrelated components, or sub-systems, with a particular purpose • There are at least 2 components • Each is related (directly or indirectly) to every other component • No subset of which is unrelated to any other subset ITEC4040 – Requirements Management

  10. Requirements Engineering Job • According to Denys Lasdun, an English architect • “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 t he time.” ITEC4040 – Requirements Management

  11. Inadequate/Misunderstood Requirements • Denver International Airport (1990 – 2005) • Originally billed as the most advanced system in the world, the baggage handling system at the airport was to become the most notorious examples of project failure • Planned to automate the handling of baggage through the entire airport • The airport was inoperable for 16 months starting in 1993 while engineers worked on getting the baggage system to work, costing USD$560 million (~CDN$988 million today) ITEC4040 – Requirements Management

  12. Inadequate/Misunderstood Requirements • Denver International Airport (1990 – 2005) • When implemented, the system only supported outbound flights on a single concourse (area where baggage is gathered) instead of the planned 3 • All other baggage was handled manually with a tug and trolley system that was built hastily when the realization the system would not meet the goals ITEC4040 – Requirements Management

  13. Inadequate/Misunderstood Requirements • Denver International Airport (1990 – 2005) • The portion of the system that was implement never functioned properly and in 2005 it was scrapped • System had a $1 million maintenance cost, that outweighed the value of the existing system (either in whole or in parts) • Manual system cut significant costs • Main cause of failure: improper requirements and requirements gathering • Underestimation of complexity, schedule and budget • Constant changes in requirements • Dismissal of advice from experts • Case study URL: • http://calleam.com/WTPF/wp-content/uploads/articles/DIABaggage.pdf ITEC4040 – Requirements Management

  14. Inadequate/Misunderstood Requirements • London Ambulance Service (1987 – 1992) • Originally operated manually until 1987 when an automatic service was introduced • It dealt with over 2000 calls on an average day with a fleet of 750 vehicles with a paper-based system ITEC4040 – Requirements Management

  15. Inadequate/Misunderstood Requirements • London Ambulance Service (1987 – 1992) • Two attempts to automate • First attempt in 1987 cost £7.5 million (~CDN$26.8 million today) • Abandoned in 1990 after it was found the system would not cope under the expected load • Second attempt in 1990 cost £1.5 million (~CDN$5.4 million today) • System had to be shut down within 24 ITEC4040 – Requirements Management

  16. Inadequate/Misunderstood Requirements • London Ambulance Service (1987 – 1992) • Two attempts to automate • Second attempt in 1990 cost £1.5 million (~CDN$5.4 million today) • On launch the system didn’t function well when it was given incomplete data regarding the status of the ambulances and the system did not accept errors made that occurred in normal day-to-day operations • The interface had black spots that meant the user couldn’t see all the information on screen • The system stored incident information even after it was not needed, causing the system to fill up memory and fail • 20-30 people died as a result of the failures, including one asthmatic 14 year old boy and a 83 year old man ITEC4040 – Requirements Management

  17. Inadequate/Misunderstood Requirements • London Ambulance Service (1987 – 1992) • Main cause of failure: improper requirements and requirements gathering • Ambulance crews (key parts in the system) had little involvement • Most work was done by contract analysts and systems managers without official sign-off by the London Ambulance Service • Failure to follow the guidelines of the UK Government project management methodology, know as the PRINCE (Project in Controlled Environment) in the design and implementation of the project and no one on the project had experience using the methodology • No independent software quality assurance team • No integration testing occurred • Incomplete software and sub-systems (Central Ambulance Control system unable to communicate properly with the Mobile data system) ITEC4040 – Requirements Management

  18. Inadequate/Misunderstood Requirements • London Ambulance Service (1987 – 1992) • More information: • https://www.cs.kent.ac.uk/teaching/09/modules/CO/8/86/rdl/CaseStudies/Reports/reportLondonAmbulanceS.pdf • http://erichmusick.com/writings/technology/1992-london-ambulance-cad-failure.html ITEC4040 – Requirements Management

  19. Inadequate/Misunderstood Requirements • Lessons: • Flaws in the production process leads to unhappy clients, high costs, and other serious negative consequences ITEC4040 – Requirements Management

  20. European Questionnaire • A questionnaire was sent to 3805 companies regarding what the Analysts believe to be the major problems in relation to system development. The results concluded from the study suggested: • Requirements specification (53%) • Requirements management (43%) • Documentation (36%) • Testing (35%) ITEC4040 – Requirements Management

  21. Good and Bad News • According to the Standish Group, CHAOS Report in 2000: • “26% of the Software projects were considered a success” • This means that 74% of the projects have failed • According to Tom DeMarco, an American software engineer and early developer of structured analysis in the 1980s • “56% of the errors in a software can be traced back to the requirements phase” • The later an error is detected, the more expensive it is to fix • Many errors are created during the Requirements Elicitation and Analysis phase • As many errors as possible should be detected early in the software development lifecycle • Of the biggest concerns for the software industry as 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 • Typical errors: incorrect facts, omissions, inconsistencies and ambiguity ITEC4040 – Requirements Management

  22. Cost to Repair Vs Stage when it is Found ITEC4040 – Requirements Management

  23. Some 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 ITEC4040 – Requirements Management

  24. Problems with Requirements • Requirements don’t reflect the real needs of the customer for the system • Requirements are inconsistent and/or incomplete • You’ll never have a complete set of requirements (Known as The Completeness Fallacy) • Not always possible to have consistent requirements as design and manufacturing constraints may clash with other requirements • Expensive to make changes to requirements after they have been agreed • There are misunderstandings between customers, those developing the system requirements and software engineers developing or maintaining the system ITEC4040 – Requirements Management

  25. Forming Requirements • Readers of requirement documents usually relate more to implementation descriptions better than abstract problem statements. Keep requirements short and to the point • The system being developed is almost always one of several systems being used. To be compatible and conform to organizational standards, you may have to specify implementation policies that constrain the options of the system designers ITEC4040 – Requirements Management

  26. Types of Requirements • Functional Requirements • Are the requirements that are directly related to the software functionality • What the system must do • Non-Functional Requirements • Express constraints that a software must comply with • Can be seen as specific qualities that a software must have • How the software must accomplish the FR • E.g.: Safety, accuracy, usability, security • Inverse Requirements (Requirements-1) • Conditions that must never happen • Frequently associated to a NFR ITEC4040 – Requirements Management

  27. Requirement Examples and Practice • The system should provide a form to enter results for clinical tests that are performed for a client • FR – Functional Requirement • If a patients glucose level is over 8.0, only the supervisor can enter the result for this patient • Non-Functional Requirement (NFR: Safety) • The system should give the client a receipt. This should take no longer than 8 seconds • (FR & NFR: Performance) • The system can not erase any client information • Inverse Requirement(IN) ITEC4040 – Requirements Management

  28. Definition of Requirements Engineering “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 [relatively] new area of study, 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 future implementation of these requirements as a software.” ITEC4040 – Requirements Management

  29. Definition of Requirements Engineering “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” ITEC4040 – Requirements Management

  30. Goals in Requirements Engineering • 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 ITEC4040 – Requirements Management

  31. Requirements Engineering Process • This is a structured process that has a set of activities that derive, validate and maintain a systems requirement document • Process activities include: • Requirements elicitation – Requirements are discovered • Requirements analysis and Negotiation – Requirements are analyzed to identify conflicts, incomplete information, or any other issues. Negotiation is needed to ensure conflicts and issues are resolved • Requirements documentation – Agreed requirements are documented in an appropriate format and level of detail • Requirements Validation – Requirements needs to be checked for consistency and completeness before it is used as the base for the system development • There is no single process that is right of all organizations. They must develop their own process that is right for them • Developing an adequate process for an organization may require the help of outside consultant that is involved in requirements engineering ITEC4040 – Requirements Management

  32. Problems in Requirements Engineering • Lack of stakeholder involvement • Business needs are not considered • Lack of requirements management • Lack of defined responsibilities • Stakeholder communication problems • Over-long schedules and poor quality requirement documents • Pressure from the Marketand unrealistic expectations • “It has to be ready next week” • Scope creep ITEC4040 – Requirements Management

  33. Process Improvement • Process improvement is concerned with modifying processes in order to meet some improvement objectives • Improvement objects can be: • Quality improvement • Schedule reduction • Resource reduction ITEC4040 – Requirements Management

  34. Planning Process Improvement • What are the problems with the current processes? • What are the improvement goals? • How can the process improvement be introduced to achieve these goals? • How should process improvements be controlled and managed? ITEC4040 – Requirements Management

  35. Process Maturity • Process maturity can be thought of as the extent that an organization has defined its processes, actively controlling these processes and providing 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 ITEC4040 – Requirements Management

  36. Process Maturity Model Overview ITEC4040 – Requirements Management

  37. Req. Eng. Process Maturity Levels • Initial Level • There is no requirement engineering process • Projects suffer from requirement problems such as requirements quality, unsatisfied stakeholders and high rework costs • Dependent on individual skills and experiences • Typically in a dynamic state of change, tending to be guided in an ad hoc fashion • A chaotic and unstable environment ITEC4040 – Requirements Management

  38. Req. Eng. Process Maturity Levels • Repeatable Level • There are defined standards for requirement documents, policies, and procedures for requirement management • Processes are repeatable with consistent results • Unlikely to be followed rigorously • Defined Level • There is a defined requirements engineering process based on good practices and techniques • Active process improvement processes are in place • Processes are used to establish consistency of process performance across the organization ITEC4040 – Requirements Management

  39. Req. Eng. Process Maturity Levels • Managed Level • There are detailed measurements of both process and product quality, and they are collected and used to control the process and to adapt to unique situations without measurable loss of quality or deviations from the specifications • Optimizing Level • The organization has a continuous process improvement strategy that is based on objective measurements done through incremental and innovative technological changes/improvements ITEC4040 – Requirements Management

  40. Why Requirements Engineering? • To quote Von Neumann, a Hungarian-American pure and applied mathematician, physicist, and polymath who made significant contributions to computing • “There is no sense in being precise when you don’t even know what you’re talking about” ITEC4040 – Requirements Management

  41. Spiral Model of the Req. Engineering Process ITEC4040 – Requirements Management

  42. Definitions • Universe of Discourse • It is the context the software should be developed and operated • Includes all sources of information and all people related to the software • Known as actors of this universe • Circumstantiated by the set of goals defined by those who demand the software ITEC4040 – Requirements Management

  43. Requirements Document • Also known as functional specification, the requirements definition, the software requirements specification (SRS), etc. • It’s a official formal statement of the system requirements for customers, end-users, system and software developers • Contains • Services and functions the system should provide • Constraints under which the system should operate • Definitions of other systems which the system must integrate with • Information about the domain of discourse • Constraints on the process used to develop the system ITEC4040 – Requirements Management

  44. Requirements Document • Popular requirements document standards are the IEEE 830-1993 standard (download) and the IEEE 830-1998 standard (download) • They generally suggest the following structure: • 1. Introduction • 1.1. Purpose of the requirements document • 1.2. Scope of the product • 1.3. Definitions, acronyms and abbreviations • 1.4. References • 1.5. Overview of the remainder of the document • 2. General Description • 2.1. Product perspective • 2.2. Product functions • 2.3. User characteristics • 2.4. General constraints • 2.5. Assumptions and dependencies • 3. Specific requirements • 4. Appendices • 5. Index ITEC4040 – Requirements Management

  45. Requirements Document • IEEE standard is not ideal for everyone, but it is a good starting point • A requirements document standard must allow for differences between systems and should allow omissions of existing sections and additions of new sections ITEC4040 – Requirements Management

  46. Final Thoughts and a Comic ITEC4040 – Requirements Management

  47. The End Questions? Lecture 01 ITEC4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

More Related