INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.

INFO 627 Lecture #1 1

Requirements Engineeringand ManagementINFO 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

Requirements are also often a contractual mechanism to express your customer’s desires and needs


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 = $$$


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…


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


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


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


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


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


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


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


Software Life Cycle (Waterfall)

Coding &Unit Test

DetailedDesign

SystemTesting

Conceptual Development

Architectural Design

RequirementsAnalysis

Coding &Unit Test

DetailedDesign

SystemTesting








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


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


Why do Projects Succeed? Conversely, projects succeed most often

because of: User involvement (16%) Top management support (14%) Clear requirements (12%)


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


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!


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


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?


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!


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


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


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


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


Varying Level of Detail

Needs

Features

Requirements

Specifications

Describes customer problem

Describes characteristics of the solution

More detail


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


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?


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.


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…)


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


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


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


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


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


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


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


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


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


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?


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?


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


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?


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

Date post:	03-Jan-2016
Category:	Documents
Upload:	junior-merritt
View:	216 times
Download:	1 times

INFO 627Lecture #11 Requirements Engineering and Management INFO 627 Introduction Glenn Booker.

Documents