software requirement analysis software requirement specification n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Requirement Analysis & Software Requirement Specification PowerPoint Presentation
Download Presentation
Software Requirement Analysis & Software Requirement Specification

Loading in 2 Seconds...

play fullscreen
1 / 30

Software Requirement Analysis & Software Requirement Specification - PowerPoint PPT Presentation


  • 232 Views
  • Uploaded on

Software Requirement Analysis & Software Requirement Specification. Prepared By: Shrestha Roshan. Requirements Engineering. Requirements engineering = gathering, negotiating, analyzing, and documenting requirements

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 'Software Requirement Analysis & Software Requirement Specification' - berg


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
software requirement analysis software requirement specification

Software Requirement Analysis & Software Requirement Specification

Prepared By:

ShresthaRoshan

requirements engineering
Requirements Engineering

Requirements engineering = gathering, negotiating, analyzing, and documenting requirements

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

requirement introduction
Requirement: Introduction
  • "If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.“

-Davis

requirement introduction1
Requirement: Introduction
  • Requirements = services the system is expected to provide + constraints placed on the system
  • Software requirements are documentation that completely describes the behavior that is required of the software-before the software is designed built and tested.
  • The requirements could be expressed at various levels of abstraction.
  • The way requirements are defined has a major impact on the development of the software product.
requirement analysis specification definition
Requirement Analysis & Specification Definition

Requirements Specification

  • A document clearly and precisely describes each of the essential requirements of the software and the external interfaces(functions, performance, design constraint, and quality attributes).
  • Each requirement is defined in such a way that its achievement is capable of being objectively verified by a prescribed method; for example inspection, demonstration, analysis, or test.

Requirements Analysis

  • The process of studying and analyzing the customer and the user/stakeholder needs to arrive at a definition of software requirements.
requirements types
Requirements: Types

A classification of requirements:

User requirements: higher level description of services requested and constraints imposed

System requirements: a more detailed, structured description of services and constraints. Usually included in the contract between the developer and the client

An even more detailed description of requirements can be provided in a software design specification (closer to implementation)

examples of user requirements definition and system requirements specification
Examples of user requirements definition and system requirements specification

User Requirement Definition

  • The software must provide a means of representing and accessing external files created by other tools.
  • System requirements specification
  • 1.1The user should be provided with facilities to define the type of external files.
  • 1.2 Each external file type may have an associated tool which may be applied to the file.
  • 1.3 Each external file type may be represented as a specific icon on the user’s display.
  • 1.4 Facilities should be provided for the icon representing an external file type to be defined by the user.
  • 1.5 When a user selects an icon representing an external file, the effect of that selection is to apply the tool associated with the type of the external file represented by the selected icon.
user requirements
User Requirements
  • Should be understood by the user, and should not address design and implementation aspects
  • Should focus on the key facilities required
system requirements
System Requirements
  • More detailed specifications of user requirements
  • Included in the contract with the client
  • Used by developers as basis for design
  • May be specified using various models (object-oriented models, data-flow diagrams, formal specs, etc.)
  • Should indicate WHAT the system is required to do (not HOW) and under what conditions and constraints
system requirements types
System Requirements: Types
  • Functional requirements, describe the requested functionality/behaviour of the system: services (functions), reactions to inputs, exceptions, modes of operations.
  • Non-functional requirements, represent constraints on the system and its functionality: performance constraints, compliance with standards, constraints on the development process.
  • Domain requirements, can be either functional or non-functional and reflect the particularities of the application domain.
non functional requirements types
Non Functional Requirements: Types
  • Product requirements
    • Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
  • Organisational requirements
    • Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.
  • External requirements
    • Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
a classification of non functional requirements
A Classification of Non-Functional Requirements

Non-functional Requirements

Product Requirements

Organizational Requirements

External Requirements

Interoperability Requirements

Efficiency Requirements

Portability Requirements

Delivery Requirements

Ethical Requirements

Implementation Requirements

Usability Requirements

Reliability Requirements

Legislative Requirements

Standards Requirements

Performance Requirements

Space Requirements

Privacy Requirements

Safety Requirements

what vs how dilemma
What Vs How Dilemma

User Requirements

We learn what the user needs are.

We propose how to address them by defining system requirements.

We specify what we are going to build in system requirements.

We describe how to address this by designing the system.

The system design says what we are going to build.

The software requirements tell how we will build part of the system in software.

The software requirements tell what we will build in software.

The software design how we are going to structure the software.

The software design tells what software structure we will build.

The code tells how this will be implemented.

What

How

System Requirements

What

How

System Design

What

How

Software Requirements

What

How

Software Design

slide16
“Walking on water and developing software from a specification are easy if both are frozen.”- Edward V. Berard
requirement analysts
Requirement Analysts
  • Requirements analysts (or business analysts) build software requirements specifications through requirements elicitation.
    • Interviews with the users, stakeholders and anyone else whose perspective needs to be taken into account during the design, development and testing of the software
    • Observation of the users at work
    • Distribution of discussion summaries to verify the data gathered in interviews
discussion summary outline

Project background

    • Purpose of project
    • Scope of project
    • Other background information
  • Perspectives
    • Who will use the system?
    • Who can provide input about the system?
  • Project Objectives
    • Known business rules
    • System information and/or diagrams
    • Assumptions and dependencies
    • Design and implementation constraints
  • Risks
  • Known future enhancements
  • References
  • Open, unresolved or TBD issues
Discussion Summary Outline
software requirement specifications
Software Requirement Specifications

The software requirements specification (SRS) represents a complete description of the behavior of the software to be developed.

The SRS includes:

A set of use cases that describe all of the interactions that the users will have with the software.

All of the functional requirements necessary to define the internal workings of the software: calculations, technical details, data manipulation and processing, and other specific functionality that shows how the use cases are to be satisfied

Nonfunctional requirements, which impose constraints on the design or implementation (such as performance requirements, quality standards or design constraints).

software requirement specification document
Software Requirement Specification Document
  • SRS structure according IEEE/ANSI 830-1993 standard (overview only, many more details are given in the standard):
    • Introduction
    • General description
    • Specific requirements
    • Appendices
    • Index
  • This structure needs to be tailored for each particular organization
problem with natural language
Problem with Natural Language

Lack of clarity

Precision is difficult without making the document difficult to read.

Requirements confusion

Functional and non-functional requirements tend to be mixed-up.

Requirements amalgamation

Several different requirements may be expressed together.

alternative to natural language
Alternative to Natural Language
  • An alternative to natural language (NL) for software specification is Program Description Languages (PDL)
    • Derived from programming languages
    • May contain more abstract constructs
    • Their syntax and semantics could be checked
    • Recommended for describing sequences of actions whose order is important & for specifying software interfaces
    • However, PDL specification require advised readers, can be taken as design specs, and may not be expressive enough
requirement imprecision
Requirement Imprecision

Problems arise when requirements are not precisely stated.

Ambiguous requirements may be interpreted in different ways by developers and users.

Consider the term ‘appropriate viewers’

User intention - special purpose viewer for each different document type;

Developer interpretation - Provide a text viewer that shows the contents of the document.

requirements problems
Requirements Problems
  • Database requirements includes both conceptual and detailed information
    • Describes the concept of a financial accounting system that is to be included in LIBSYS;
    • However, it also includes the detail that managers can configure this system - this is unnecessary at this level.
  • Grid requirement mixes three different kinds of requirement
    • Conceptual functional requirement (the need for a grid);
    • Non-functional requirement (grid units);
    • Non-functional UI requirement (grid switching).
requirement completeness and consistency
Requirement Completeness And Consistency

In principle, requirements should be both complete and consistent.

I. Complete

They should include descriptions of all facilities required.

II. Consistent

There should be no conflicts or contradictions in the descriptions of the system facilities.

In practice, it is impossible to produce a complete and consistent requirements document.

slide29

There is no perfect software, perfect system, perfect language or perfect code block that’s the whole reason “exceptions” were introduced and catching them made it into one of best practices.-Unknown

key points
Key Points
  • Requirements set out what the system should do and define constraints on its operation and implementation.
  • Functional requirements set out services the system should provide.
  • Non-functional requirements constrain the system being developed or the development process.
  • User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.
  • System requirements are intended to communicate the functions that the system should provide.
  • A software requirements document is an agreed statement of the system requirements.
  • The IEEE standard is a useful starting point for defining more detailed specific requirements standards.