The requirements problem chapter 1
Download
1 / 18

The Requirements Problem Chapter 1 - PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on

The Requirements Problem Chapter 1. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' The Requirements Problem Chapter 1' - aulii


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Standish group research
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




Relative cost to repair a defect at different life cycle phases
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


Key points
Key Points Phases

  • Goal of software development is to develop quality software–on time and on budget–that meets customer’s 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



What is a software requirement
What is a Software Requirement? Phases

  • 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 system…to 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]


Types of software applications
Types of Software Applications Phases

  • 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.


Requirements management
Requirements Management Phases

  • 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


Requirements elicitation
Requirements Elicitation Phases

• 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.


Requirements analysis and negotiation
Requirements Analysis and Negotiation Phases

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.


Requirements analysis and negotiation1
Requirements Analysis and Negotiation Phases

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?


Requirements specification
Requirements Specification Phases

  • 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.


Requirements validation
Requirements Validation Phases

  • 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.


Requirements validation1
Requirements Validation Phases

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?


Problem domain solution domain
Problem Domain & Solution Domain Phases

Needs

– in user terms

Problem Domain

Features – a service provided by the system that fulfills a need

Software requirements – more specific

Solution Domain


Key points1
Key Points Phases

  • 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


ad