the functional effects that the software to be is required address the WHAT

The functional effects that the software to be is

This preview shows page 23 - 33 out of 42 pages.

the functional effects that the software-to-be is required address the 'WHAT' aspects linked to functional goals (to be discussed ) Non-functional requirements Quality requirements (linked to quality goals – to be discussed ) Compliance requirements Architectural requirements Development requirements classified with a taxonomy Non-traditional non-functional requirements Emotional requirements (linked to emotional goals – to be discussed ) Types of Requirements
Image of page 23
Quality requirements constraints on the way the software-to-be should satisfy its functional requirements Address the 'HOW WELL' aspects e.g. performance, security Compliance requirements prescribe software to conform to national laws, international regulations, social norms, cultural or political constraints, and standards Architectural requirements impose architectural constraints on the software-to-be Development requirements constrain the way it should be developed requirements on development costs, delivery schedules, variability of features, maintainability, reusability and portability Non-Functional Requirements
Image of page 24
One taxonomy for classification: Taxonomy A.V, L. (2014). Requirements Engineering: From System Goals to UML Models to Software Specifications (1 edition). Wiley India.
Image of page 25
What are the 4 types of Non-functional requirements? Briefly describe. [ quick pause ] Think about it…
Image of page 26
Quality requirements
Image of page 27
Safety requirements rule out software effects that might result in accidents, degradations or losses Train Control System The controlled accelerations of trains shall always guarantee that a worst-case stopping distance is maintained between successive trains Quality requirements
Image of page 28
Security requirements prescribe the protection of system assets against undesirable behaviors split into 3 subcategories 1. Confidentiality requirements some sensitive information may never be disclosed unauthorized parties Library Management System A non-staff patron may never know which books have been borrowed by others Quality requirements
Image of page 29
Security requirements 2. Integrity requirements some information may be modified only if correctly done and with authorization Library Management System The return of book copies shall be encoded correctly and by library staff only Quality requirements
Image of page 30
Security requirements 3. Availability requirements some information or resource can be used at any point in time when it is needed and its usage is authorized Train Control System: Information about train positions shall be available at any time to the vital station computer Quality requirements
Image of page 31
In the context of quality requirements, define security.
Image of page 32
Image of page 33

You've reached the end of your free preview.

Want to read all 42 pages?

  • One '14
  • Requirements analysis

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture