software requirements
Download
Skip this Video
Download Presentation
Software Requirements

Loading in 2 Seconds...

play fullscreen
1 / 20

Software Requirements - PowerPoint PPT Presentation


  • 153 Views
  • Uploaded on

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.

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 Requirements' - abie


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

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

ad