Mastering Software Requirements for Quality Systems

1. Software Requirements By: Eshcar Hilel Michael Beder

2. Agenda • Definitions • Quality Gateway • Example: Traffic Violation Reports System Software Requirements

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

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

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

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

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

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

9. Software Requirements

10. Quality Gateway

11. Quality Gateway Examine each requirement before entering the specification: • Completeness • Traceability • Consistency • Ambiguity • Deal only with the problem • Testability • Gold Plating Software Requirements

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

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

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

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

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

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

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

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

20. TVRS – Traffic Violation Report System Request for Proposal