Requirements Engineering and Management INFO 627

1
Requirements Engineeringand ManagementINFO 627

• Introduction
• Glenn Booker

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 customers desires and
  needs

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

4
Huh? Whats a Requirement?

• A requirement is some characteristic or
  capability which the final product (software
  and/or system) should deliver
• Well refine this definition later

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

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 doesnt do much ?

7
Whos 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

8
Whos 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

9
Whos 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

10
The Challenge

• A major challenge in producing good requirements
  is that you must be a liaison between the
  customers world and the technology world
• You may have to learn their language, and phrase
  requirements to help make the technology meet
  their needs

11
Software Life Cycle

• Requirements are mostly found early in the life
  cycle, then refined throughout the rest of the
  products life (even through maintenance)
• Hence requirements management occurs throughout
  the entire life of the product

12
Software Life Cycle (Waterfall)
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

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

15
Why do Projects Succeed?

• Conversely, projects succeed most often because
  of
• User involvement (16)
• Top management support (14)
• Clear requirements (12)

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

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.
• Thats why late changes to requirements are so
  expensive!

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

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?

20
Guidance for Reqts Management
Reqts 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.

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

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

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

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

25
Varying Level of Detail
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

27
Is it a Requirement?

• Or is someone designing the system prematurely?
• Beware of requirements or constraints which
  arent really needed
• Is someone describing the solution (the system)
  instead of the problem?
• Is it too vague to be a requirement?

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.

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)

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

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

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

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

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

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

36
Six Team Skills

• Analyzing the Problem
• Understanding User Needs
• Defining the System
• Managing Scope
• Refining the System Definition
• Building the Right System

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
  customers motivation for creating a new system

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

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 products vision so it
  doesnt become garbled over time?

40
4. Managing Scope

• Requirements are rarely static they may change
  faster than a three-year-olds attention span
• How do we keep the products scope from growing
  out of control?
• How can we pare down the scope if we cant get
  everything done on time?

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

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
  customers needs?
• How do we control changes to the requirements?

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
  well discuss common aspects and characteristics