INFO 355Week #31 Systems Analysis II Domain Modeling INFO 355 Glenn Booker.
INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.
-
Upload
junior-merritt -
Category
Documents
-
view
217 -
download
1
Transcript of INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.
![Page 1: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/1.jpg)
INFO 627 Lecture #1 1
Requirements Engineeringand ManagementINFO 627
Introduction
Glenn Booker
![Page 2: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/2.jpg)
INFO 627 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
![Page 3: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/3.jpg)
INFO 627 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 = $$$
![Page 4: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/4.jpg)
INFO 627 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…
![Page 5: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/5.jpg)
INFO 627 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
![Page 6: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/6.jpg)
INFO 627 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
![Page 7: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/7.jpg)
INFO 627 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
![Page 8: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/8.jpg)
INFO 627 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
![Page 9: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/9.jpg)
INFO 627 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
![Page 10: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/10.jpg)
INFO 627 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
![Page 11: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/11.jpg)
INFO 627 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
![Page 12: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/12.jpg)
INFO 627 Lecture #1 12
Software Life Cycle (Waterfall)
Coding &Unit Test
DetailedDesign
SystemTesting
Conceptual Development
Architectural Design
RequirementsAnalysis
Coding &Unit Test
DetailedDesign
SystemTesting
Conceptual Development
Architectural Design
RequirementsAnalysis
Conceptual Development
Architectural Design
RequirementsAnalysis
![Page 13: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/13.jpg)
INFO 627 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
![Page 14: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/14.jpg)
INFO 627 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
![Page 15: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/15.jpg)
INFO 627 Lecture #1 15
Why do Projects Succeed? Conversely, projects succeed most often
because of: User involvement (16%) Top management support (14%) Clear requirements (12%)
![Page 16: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/16.jpg)
INFO 627 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
![Page 17: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/17.jpg)
INFO 627 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!
![Page 18: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/18.jpg)
INFO 627 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
![Page 19: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/19.jpg)
INFO 627 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?
![Page 20: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/20.jpg)
INFO 627 Lecture #1 20
Guidance for Req’ts Management 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.
Req’ts = Requirements … get used to it!
![Page 21: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/21.jpg)
INFO 627 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
![Page 22: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/22.jpg)
INFO 627 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
![Page 23: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/23.jpg)
INFO 627 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
![Page 24: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/24.jpg)
INFO 627 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
![Page 25: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/25.jpg)
INFO 627 Lecture #1 25
Varying Level of Detail
Needs
Features
Requirements
Specifications
Describes customer problem
Describes characteristics of the solution
More detail
![Page 26: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/26.jpg)
INFO 627 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
![Page 27: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/27.jpg)
INFO 627 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?
![Page 28: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/28.jpg)
INFO 627 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.
![Page 29: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/29.jpg)
INFO 627 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…)
![Page 30: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/30.jpg)
INFO 627 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
![Page 31: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/31.jpg)
INFO 627 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
![Page 32: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/32.jpg)
INFO 627 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
![Page 33: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/33.jpg)
INFO 627 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
![Page 34: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/34.jpg)
INFO 627 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
![Page 35: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/35.jpg)
INFO 627 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
![Page 36: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/36.jpg)
INFO 627 Lecture #1 36
Six Team Skills1. Analyzing the Problem
2. Understanding User Needs
3. Defining the System
4. Managing Scope
5. Refining the System Definition
6. Building the Right System
![Page 37: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/37.jpg)
INFO 627 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
![Page 38: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/38.jpg)
INFO 627 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
![Page 39: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/39.jpg)
INFO 627 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?
![Page 40: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/40.jpg)
INFO 627 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?
![Page 41: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/41.jpg)
INFO 627 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
![Page 42: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/42.jpg)
INFO 627 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?
![Page 43: INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.](https://reader035.fdocuments.net/reader035/viewer/2022062517/56649ef25503460f94c043a9/html5/thumbnails/43.jpg)
INFO 627 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