The Requirements Problem

1

• The Requirements Problem
• Chapter 1

2
Standish Group Research

• Research paper at
• http//www.standishgroup.com/sample_research/chaos
  _1994_1.php (1994)
• 31.1 of project get canceled before they ever
  get started
• 52.7 of projects will cost 189 of their
  original estimates
• The failure to produce reliable software to
  handle baggage at the new Denver airport is
  costing the city 1.1 million per day
• 16.2 of software projects are completed on-time
  and on-budget

3
IT executive managers on their opinions about why
projects succeed
Project Success Factors of Responses
1. User Involvement 15.9
2. Executive Management Support 13.9
3. Clear Statement of Requirements 13.0
4. Proper Planning 9.6
5. Realistic Expectations 8.2
6. Smaller Project Milestones 7.7
7. Competent Staff 7.2
8. Ownership 5.3
9. Clear Vision Objectives 2.9
10. Hard-Working, Focused Staff 2.4
Other 13.9
4
IT executive managers on their opinions about why
projects are challenged
Project Challenged Factors of Responses
1. Lack of User Input 12.8
2. Incomplete Requirements Specifications 12.3
3. Changing Requirements Specifications 11.8
4. Lack of Executive Support 7.5
5. Technology Incompetence 7.0
6. Lack of Resources 6.4
7. Unrealistic Expectations 5.9
8. Unclear Objectives 5.3
9. Unrealistic Time Frames 4.3
10. New Technology 3.7
Other 23.0
5
Relative Cost to Repair a Defect at Different
Life Cycle Phases
.1-.2
Analysis
Unit cost of 1 is assigned to effort required to
detect and repair an error during the coding
stage, then the cost to detect and repair during
the requirements stage is 5 to 10 times less
.5
Design
Coding
1
2
Unit Test
5
Acceptance Test
20
Maintenance
6
Key Points

• Goal of software development is to develop
  quality softwareon time and on budgetthat meets
  customers real needs
• Project success depends on effective requirements
  management
• Requirements error are the most common type of
  systems development errors and the most costly to
  fix
• A few key skills can significantly reduce
  requirements errors and thus improve software
  quality

7

• Intro to Requirements Management
• Chapter 2

8
What is a Software Requirement?

• Software capability needed by the user to solve a
  problem to achieve an objective Dorfman
• System Requirements define what the system is
  required to do and the constraints under which it
  is required to operate Sommerville
• Software capability that must be met or possessed
  by a systemto satisfy a contract, standard,
  specification, or other formally imposed
  documentation Dorfman
• (1) A characteristic that a system or software
  item is required to possess in order to be
  acceptable to the acquirer. (2) A binding
  statement Requirements are expressed using the
  word shall. IEEE/EIA J-STD-016

9
Types of Software Applications

• Information systems and other applications
  developed for use within a company.
• Software developed and sold as commercial
  products.
• Software that runs on computers embedded in other
  devices, machines, or complex systems.

10
Requirements Management

• Systematic approach to
• Elicit
• Organize
• Document
• Process that establishes and maintains agreements
  on the changing requirements of the system
• Engineering Review Boards
• Change Control Boards

11
Requirements Elicitation

• Assess the business and technical feasibility
  for the proposed system.
• Identify the people who will help specify
  requirements and understand their organizational
  bias.
• Define the technical environment (e.g.,
  operating system, telecommunications needs) into
  which the system or product will be placed.
• Identify domain constraints (i.e.,
  characteristics of the business environment
  specific to the application domain) that limit
  the functionality or performance of the system or
  product to be built.
• Define one or more requirements elicitation
  methods (e.g., interviews, focus groups, team
  meetings).
• Solicit participation from many people so that
  requirements are defined from different points of
  view.

12
Requirements Analysis and Negotiation

• Analysis categorizes requirements and organizes
  them into related subsets explores each
  requirement in relationship to others examines
  requirements for consistency, omissions, and
  ambiguity and ranks requirements based on the
  needs of customers/users.

13
Requirements Analysis and Negotiation

• As the requirements analysis activity commences,
  the following questions are asked and answered
• Is each requirement consistent with the overall
  objective for the system/product?
• Have all requirements been specified at the right
  level of abstraction?
• Is the requirement really necessary or does it
  represent an add-on feature that may not be
  essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Do any requirements conflict with other
  requirements?
• Is each requirement achievable in the technical
  environment that will house the system or
  product?
• Is each requirement testable, once implemented?

14
Requirements Specification

• The System Specification is the final work
  product produced by the system and requirements
  engineer. The System Specification also describes
  the information (data and control) that is input
  to and output from the system.
• A specification can be a written document, a
  graphical model, a formal mathematical model, a
  collection of usage scenarios, a prototype, or
  any combination of these.

15
Requirements Validation

• Requirements validation examines the
  specification to ensure that all system
  requirements have been stated unambiguously that
  inconsistencies, omissions, and errors have been
  detected and corrected and that the work
  products conform to the standards established for
  the process, the project, and the product.

16
Requirements Validation

• The following questions represent a small subset
  of those that might be asked
• Are requirements clear? Can they be
  misinterpreted?
• Who is the source of the requirement? Has the
  final statement of the requirement been examined
  by or against him/her?
• What other requirements relate to this
  requirement?
• Does the requirement break any domain
  constraints?
• Is the requirement testable? If so, can we
  specify tests to implement the requirement?
• Is the requirement traceable to any system
  model that has been created?
• Is the requirement traceable to overall
  system/product objectives?

17
Problem Domain Solution Domain
Needs in user terms
Problem Domain
Features a service provided by the system that
fulfills a need
Software requirements more specific
Solution Domain
18
Key Points

• A requirement is a capability that is imposed on
  the system
• Requirements management is a process of
  systematically eliciting, organizing, and
  documenting requirements for a complex system
• Our challenge is to understand users problems in
  their culture and their language and to build
  systems that meet their needs
• A feature is a service that the system provides
  to fulfill one or more stakeholder needs
• A use case describes a sequence of actions,
  performed by a system, that yields a result of
  value to a user