1 / 43

Requirements Engineering and Management INFO 627

Requirements Engineering and Management INFO 627. Introduction Glenn Booker. Who Cares?. Requirements guide the development of a system (including its software) Therefore, clear, correct, and complete requirements are essential to producing a system which fulfills its intended purpose

osanna
Download Presentation

Requirements Engineering and Management INFO 627

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. Requirements Engineeringand ManagementINFO 627 Introduction Glenn Booker Lecture #1

  2. Who Cares? • Requirements guide the development of a system (including its software) • Therefore, clear, correct, and complete requirements are essential to producing a system which fulfills its intended purpose • Requirements are also often a contractual mechanism to express your customer’s desires and needs Lecture #1

  3. Who Cares? • Hence it is critical to define and control (manage) requirements carefully to help make sure we produce something which will make our customer happy • Happy customer = Repeat customer = $$$ Lecture #1

  4. Huh? What’s a Requirement? • A requirement is some characteristic or capability which the final product (software and/or system) should deliver • We’ll refine this definition later… Lecture #1

  5. My Background and Biases • Over 18 years of system development, mostly for government agencies (defense and FAA), and 8 years teaching for Drexel • Mostly work with long-lived systems • Tend to focus on the entire system rather than just its software Lecture #1

  6. Software vs. System • Though most of the really big mistakes occur in software, while developing requirements for a product we need to consider all of its parts (the whole system), which might also include hardware, networking, staffing, documentation, training materials, etc. • Software all by itself doesn’t do much  Lecture #1

  7. Who’s the Customer? • We will speak frequently of trying to make the ‘customer’ happy with the final product we produce • Typical types of customer represent • Commercial software development, • Custom system development, and • Classic information technology (IT) development Lecture #1

  8. Who’s the Customer? • So this mythical ‘customer’ might be: • Could be a person or organization looking to buy a shrink-wrapped commercial software product • Could be an organization who has hired us to produce a custom system to meet their needs • Could be a group within our organization who needs to perform their function using a tool we develop Lecture #1

  9. Who’s the Customer? • The customer could come from any industry (banking, retail, manufacturing, government, pharmaceuticals, entertainment, etc.) • The customer could be very technology literate, completely technology illiterate, or ANYWHERE in between Lecture #1

  10. The Challenge • A major challenge in producing good requirements is that you must be a liaison between the customer’s world and the technology world • You may have to learn their language, and phrase requirements to help make the technology meet their needs Lecture #1

  11. Software Life Cycle • Requirements are mostly found early in the life cycle, then refined throughout the rest of the product’s life (even through maintenance) • Hence requirements management occurs throughout the entire life of the product Lecture #1

  12. Software Life Cycle (Waterfall) Lecture #1

  13. Motivation • IT projects in the US cost a quarter trillion dollars each year, with each project averaging from half a million to two million dollars, depending on size of the company • Of these, 31% fail to produce a product • And half of them cost at least 90% more than planned Lecture #1

  14. Why do Projects Fail? • The most common root causes of late or poor projects are: • Lack of user input (13%) • Incomplete requirements (12%) • Changing requirements (12%) • Hence over a third of all projects get in trouble for reasons related to requirements Lecture #1

  15. Why do Projects Succeed? • Conversely, projects succeed most often because of: • User involvement (16%) • Top management support (14%) • Clear requirements (12%) Lecture #1

  16. Requirements Defects • Good projects analyze when defects were found, and when they were created • Requirements defects typically result in almost one third of all defects which are released to the customer • And requirements defects, if caught early, cost 1/10th to 1/100th of fixing them later on Lecture #1

  17. Requirements Defects • Finding defects in requirements later in the life cycle leads to many corrective actions – redesign, recoding, retesting, changes in test procedures and test cases, publication of fixes, updates to documentation, etc. • That’s why late changes to requirements are so expensive! Lecture #1

  18. Requirements Management • So to control requirements, we need • A systematic way to find, organize, and document requirements, and • A process to make sure the customer and project staff agree on changes to those requirements • Those constitute requirements management Lecture #1

  19. Requirements Management • Sounds like a simple thing, but the complexity and interdependency of modern systems can make this challenging. For any given requirement: • Who can change or delete that requirement? • If it is changed, what other requirements are affected? • Has that requirement been implemented, and do we have test cases to prove we did so correctly? Lecture #1

  20. Guidance for Req’ts Management Req’ts = Requirements … get used to it! • Industry best practices for requirements management are contained in process models, such as: • ISO 9000 – the international standard for quality management • Software Engineering Institute (SEI) Capability Maturity Models (CMMs) • Models exist for telecom, health care, etc. Lecture #1

  21. Software Applications • As noted earlier, there are three kinds of software: commercial, custom, and IT • Software size may range from 10,000 line simple applications, to 2 million lines for the Space Shuttle, to 35 million lines for Windows XP Lecture #1

  22. Software Applications • Software may be an application (shrink-wrapped commercial software), standalone system (IT), or embedded in something else (phone, sewing machine, car, etc.) • Most requirements management activities apply equally well to any kind of system, including any kind of software Lecture #1

  23. What is really a Requirement? • As soon as we try to define requirements, we encounter the need to distinguish among many kinds of things that could sound like requirements • A need is some characteristic of the system that the customer must have to be able to perform their function Lecture #1

  24. What is really a Requirement? • A feature describes what the system will be able to accomplish • A requirement describes some capability or characteristic of the system • A specification describes how a requirement will be implemented Lecture #1

  25. More detail Describes customer problem Needs Features Describes characteristics of the solution Requirements Specifications Varying Level of Detail Lecture #1

  26. What is really a Requirement? • An opportunity is a new feature, type of product, type of customer, or other way to expand the usability of a product • A problem is something wrong with the way the customer currently performs some activity • A constraint limits our options for how the system will be designed or implemented Lecture #1

  27. Is it a Requirement? • Or is someone designing the system prematurely? • Beware of “requirements” or constraints which aren’t really needed • Is someone describing the solution (the system) instead of the problem? • Is it too vague to be a requirement? Lecture #1

  28. Priorities • What is the priority or urgency of a requirement? • High, Medium, or Low • Required, Desired, or Optional • Must-have, want-to-have, or nice-to-have • In contract terminology, shall means required, should means desired, and may means optional • Or assign numeric value; 1-3, 1-5, etc. Lecture #1

  29. Stakeholders • We spoke of the ‘customer’ as a single entity, but there may be many conflicting kinds of people interested in the resulting product (stakeholders) • The ‘sponsor’ is whoever pays for the product, and has final say in what are its requirements (think Golden Rule – whoever has the gold…) Lecture #1

  30. Stakeholders • The ‘developer’ is generally you, whoever is designing and creating the product • There may be technical ‘Subject Matter Experts’ (SMEs) who help define requirements for part of the system – they generally know their part, and little else • The ‘end user’ of the system is whoever uses it on a daily basis to perform their job Lecture #1

  31. Stakeholders • There may be ‘managers’ between sponsor and end user in the food chain, who use the product occasionally • There may be ‘administrators’ for the system, who operate it and take care of it • Could include people who only run backup • Major ‘vendors’ may provide key parts of the system, and help maintain them Lecture #1

  32. Stakeholders • Each of these kinds of stakeholders may have separate and/or conflicting requirements for the system • Another challenge for successful system development is to reconcile these requirements so that everyone is happy Lecture #1

  33. Stakeholders • For example, an air traffic control (ATC) system might have: • Sponsor: Congress • Developer, SME, and Manager: FAA experts • End user: Members of ATC union • Administrator: Site-specific FAA employees • Vendors: IBM, Rational, and Cisco Lecture #1

  34. The Software Team • Everyone involved in developing a system is affected by requirements management, though in very different ways • Trouble is, most developers are not people people (sic) • However the complexity of modern systems makes it necessary to interact with *yuck* people Lecture #1

  35. Development Team • Teams can run to hundreds of people, many of whom could be affected by any particular requirements change • In fact, team productivity does not depend on having high individual productivity • Consistent with process models, which discourage the solo “cowboy” mentality Lecture #1

  36. Six Team Skills • Analyzing the Problem • Understanding User Needs • Defining the System • Managing Scope • Refining the System Definition • Building the Right System Lecture #1

  37. 1. Analyzing the Problem • Any system is created to fix some sort of problem – otherwise, why bother creating the system? • So the best starting point is to understand the customer’s motivation for creating a new system Lecture #1

  38. 2. Understanding User Needs • The highest level of requirements come from figuring out how the problems can be solved • How can we determine what techniques will help extract requirements from the customer? • Like a good carpenter, need several tools from which to choose Lecture #1

  39. 3. Defining the System • Given a herd of requirements, how can we organize them and produce an overall vision of what the new system will be? • How can common requirements be shared across a family of related products? • How can we champion the product’s vision so it doesn’t become garbled over time? Lecture #1

  40. 4. Managing Scope • Requirements are rarely static – they may change faster than a three-year-old’s attention span • How do we keep the product’s scope from growing out of control? • How can we pare down the scope if we can’t get everything done on time? Lecture #1

  41. 5. Refining the System Definition • How can we expand on the requirements to produce enough detail to guide the developers – without doing their job for them? • Detailed requirements need to keep consistent with the vision, yet extend it until each piece is solvable Lecture #1

  42. 6. Building the Right System • How can we prove the design will meet the requirements? • How do we know the design will still meet the customer’s needs? • How do we control changes to the requirements? Lecture #1

  43. Variety of Team Skills • Like a football team or an orchestra, each member has different skills to contribute • All aspects of the team must be met somewhere, or we might be missing a wide receiver or the French horn section! • No one structure for teams works everywhere, but we’ll discuss common aspects and characteristics Lecture #1

More Related