Software requirements
This presentation is the property of its rightful owner.
Sponsored Links
1 / 20

Software Requirements PowerPoint PPT Presentation


  • 111 Views
  • Uploaded on
  • Presentation posted in: General

Software Requirements. By: Eshcar Hilel Michael Beder. Agenda. Definitions Quality Gateway Example: Traffic Violation Reports System. Definitions. A requirement is something the system is capable of doing or a property that the system must have.

Download Presentation

Software Requirements

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 requirements

Software Requirements

By: Eshcar Hilel

Michael Beder


Agenda

Agenda

  • Definitions

  • Quality Gateway

  • Example: Traffic Violation Reports System

Software Requirements


Definitions

Definitions

  • A requirement is something the system is capable of doing or a property that the system must have.

  • The requirements must be elicited from the clients needs, expectations and constraints before starting to build the product.

Software Requirements


Definitions1

Definitions

  • The client/customer pays for the development of the product, or buys the product once it is developed (Computer center - traffic department)

  • Users will ultimately operate the product. (Police officer)

  • Stakeholder is any entity (not necessarily human) who either affects the system development or is affected by it

Software Requirements


Functional requirements

Functional requirements

  • Specify what the capability of the system

  • Actions the product must take

  • Derived from main goal of the product

  • Not a quality

  • Characterized by verbs

    • Example: TVRS shall automatically connect with the policemen, vehicles and offenders data bases

Software Requirements


Operational requirements

Operational requirements

  • Defines a behavior the product must have

  • Usually contains capabilities (functions) applied in a given behavioral context

  • Frequently is a part of a sequence of actions

Software Requirements


Non functional requirements

Non-functional requirements

  • Properties, or qualities, that the system must achieve, while satisfying its operational/functional requirements

  • Characterized by adjectives

  • Checklist:Look and feel, Usability, Performance Maintainability and Portability, etc

    • Example: The interface between the user and the system must have a maximum response time of two seconds

Software Requirements


Requirements pitfalls

Requirements Pitfalls

  • Don’t add unnecessary requirements

    • Writing requirements is a difficult task

    • Increases complexity

    • Invest the time in improving / validating the necessary requirements

  • Never assume the existence of external systems

    • Must be explicitly required by the client

  • The main goal is to increase profits

    • Avoid complex and/or expensive solutions

Software Requirements


Software requirements

Software Requirements


Quality gateway

Quality Gateway


Quality gateway1

Quality Gateway

Examine each requirement before entering the specification:

  • Completeness

  • Traceability

  • Consistency

  • Ambiguity

  • Deal only with the problem

  • Testability

  • Gold Plating

Software Requirements


Completeness

Completeness

  • A requirements document is complete if it includes all of the significant requirements, whether relating to functionality, performance, design constraints or else

  • Each requirement is a complete and independent

  • No sections are marked “to be determined” (TBD)

Software Requirements


Traceability

Traceability

  • Each requirement should be contained in a single, numbered paragraph so that it may be referred to in other documents:

    • Backward traceability - implies that we know why every requirement exists

      • Each requirement explicitly references its source in previous documents

    • Forward traceability – allocation of requirement to analysis/design elements.

Software Requirements


Consistency

Consistency

  • Different terms used for the same object:

    • F323 and a “policeman details form” might be used to describe the same form.

  • Logical or temporal faults: “A follows B” in one part, “A and B occur simultaneously” in another.

  • “TVRS shall support removal of a policeman record from the personal database” vs. “TVRS shall support read-only access to policeman details”.

Software Requirements


Ambiguity

Ambiguity

  • The difficulty of ambiguity stems from the use of natural language which in itself is inherently ambiguous

  • The requirement should be phrased so that there is one and only one interpretation for it

  • Requirement statements should be short, explicit, precise and clear

  • A glossary should be used when a term used in a particular context could have multiple meanings (I.e. “the user”)

Software Requirements


Deal only with the problem

Deal only with the problem

  • Requirements should state “what” is required at the appropriate system level, not “how”

    • However, requirements that specify “how" are still legitimate, but are considered as "design constraints"

  • The more abstract the requirement, the less likely it is to be a solution

  • Requirements should be understood by the clients as well as the developers

Software Requirements


Testability

Testability

  • A requirements document is testable (verifiable) if and only if every requirement statement in it is testable.

  • A requirement is testable if and only if there is some finite cost-effective way in which a person or machine can check to see if the software product satisfies that requirement.

    • sometimes requirements can only be tested using simulation.

Software Requirements


Testable cont

Testable (cont.)

  • Example of a non-verifiable requirement:

    • The TVRS shall complete storage of data within a reasonable time of the user confirming a “Save” sequence

  • Example of a verifiable requirement:

    • The TVRS shall complete storage of data within 5 seconds of the user confirming a “Save” sequence, 80% of the time

Software Requirements


Gold plating

Gold Plating

  • The term comes from gold plated bathroom taps.

    • Example: TVRS will play a piece of classical music during initialization

  • Does it matter if this requirement is not included?

  • Sometimes a little gold plating makes a big difference to the acceptance of the product

Software Requirements


Tvrs traffic violation report system

TVRS – Traffic Violation Report System

Request for Proposal


  • Login