430 likes | 559 Views
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
E N D
Requirements Engineeringand ManagementINFO 627 Introduction Glenn Booker Lecture #1
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
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
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
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
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
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
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
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
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
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
Software Life Cycle (Waterfall) Lecture #1
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
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
Why do Projects Succeed? • Conversely, projects succeed most often because of: • User involvement (16%) • Top management support (14%) • Clear requirements (12%) Lecture #1
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
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
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
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
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
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
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
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
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
More detail Describes customer problem Needs Features Describes characteristics of the solution Requirements Specifications Varying Level of Detail Lecture #1
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
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
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
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
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
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
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
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
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
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
Six Team Skills • Analyzing the Problem • Understanding User Needs • Defining the System • Managing Scope • Refining the System Definition • Building the Right System Lecture #1
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
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
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
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
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
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
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