SRE Lec # 4

>>>>> Download Link Here <<<<<<

In this Slide
______________________________________________________


SRE – Types of Requirements
BSEF15 (V)
Abdul Razaq Ali
Views on Requirements Types
Requirements types can be identified using different views.
1. Hardware vs. Software requirements
2. Production process requirements
3. Complete Taxonomy
1.1 Hardware vs. Software requirements
1. Hardware requirements
1. Performance requirements
2. Constraints:
1. Interface requirements
2. Specialty engineering requirements
3. Environmental requirements
1. Software requirements
1. Functional requirements
2. Nonfunctional requirements
1.2 Production Process Requirements
Complete RE Taxonomy
Requirements Types
Business requirements
Stated requirements vs real requirements
User requirements
High-level or system-level requirements
Process requirements
Qualified requirements
Non-functional requirements
Functional requirements (define business rules)
Derived requirements
Design requirements and constraints
Performance requirements
Unknowable requirements
System and component requirements
Requirements Types
Interface requirements
Verified requirements
Validated requirements
Product requirements
Logistic support requirements
Environmental requirements
Requirements
Business Requirements
Highest in the hierarchy due to its importance
 Reason for developing systems and software in the first place.
 Essential activities for an enterprise
 Any system made MUST reflect and support Business requirements
Stated vs Real Requirements
 Stated requirements are provided by a customer at the beginning of the project
 Real requirements are identified during requirements analysis phase,
Key responsibility of RA and should cover anything/everything a user wants from the system
User Requirements
 User requirements are verified needs of users from the system or software
 These are acceptance criteria of a product
Requirements
High Level or System Level Requirements
 Comprehend the required system
 Capture vision of the customer
 Enable defining scope
 Allow cost and schedule estimates required to build the system
Functional Requirements
 Business Rule Identification – provides basis for Functional requirements
 Important Category for Real requirements
 Describes what a software system must do
 Behavioral or operational requirements as they specify inputs and outputs of the system and the relationship among them
 These are depicted in Functional Specification (FS)
Requirements
Business Rules
- The policies, conditions, and constraints of the business activities supported by the
system
- The decision processes, guidelines, and controls behind the functional
requirements (e.g., procedures)
- Definitions used by the business
- Relationships and work flows in the business
- Knowledge needed to perform actions

Requirements
Non-Functional Requirements
Nonfunctional requirements specify system properties, such as reliability, performance and safety.
Derived Requirements
A derived requirement is one that is further refined from a higher-level requirement or a requirement that results from choosing a specific implementation or system element.
Design Requirements
Requirement (design constraint) may be that the system to be developed must obtain its information from an existing database.
For reasons of budget, schedule, or quality, an organization may wish to reuse some or all existing software systems in the implementation of a new system.
Requirements
Performance Requirements
How well the system should perform
Also termed as 'Dependability requirements'
One of the most difficult challenge in system development
availability, security, performance, reliability, and safety.
Interface Requirements
GUI based requirements
Identifies physical and functional relationships among system elements and modules
Verified Requirements
Verified requirements are real requirements that are met or satisfied in the design solution.
Requirements
Validated Requirements
Validated requirements are requirements that are implemented in the delivered System.
Qualification Requirements
Qualification refers to the verification or validation of item performance in a specific application and results from design review, test data review and configuration audits.
Product Requirements
These are requirements of the products that are produced by a system
Process Requirements
Requirements that exist because of the processes being used to develop the software/system
Requirements
Logistic Support Requirements
These are requirements that exist because of such things as tools, training, procedures, facilities and spares
Environmental Requirements
These are requirements that result from the physical settings an

Requirements Errors
A deficiency in the requirements quality that can hamper software development. Requirements errors are the most expensive error type to remove, almost impossible to remove when drilled down to the system
Error Types
Error of Omission: Most Common type
Domain experts easily forget to convey domain knowledge to requirements engineers, because they consider that to be obvious and implicit
Error of Clarity and Ambiguity
Primarily, because of natural languages use (like English), instead also use Use case diagrams to depict requirements
Language Barrier
Different understanding of business
“Always have Client sign off once requirements documents
are made, remade, finalized and concluded for reference”
Error of Speed and Capacity
These occur due to conflicting understanding or competing needs of different stakeholders
Negative impact of Requirements Errors
The resulting software may not satisfy user’s real needs
Multiple interpretations of requirements may cause disagreements between customers and developers, wasting time and money, and perhaps resulting in lawsuits
Negative impact on humans
Unsatisfied customers and developers
Lack of interest in automation of processes
Blame game
All of this can be avoided by using some techniques and guidelines
Defect prevention
Understand application domain and business area
Training on Requirement gathering techniques (elicitation, analysis, negotiation etc)
Join Application Development (JAD), Quality Function Deployment (DFD), Prototyping
Defect removal (Inspections, Reviews, checklist etc)
Guidelines while documenting Requirements
No vague terminology - such as “usually, often, typically, generally, user friendly, versatile, flexible, reliable, and upgradeable,” in writing requirements.
Avoid putting more than one requirement in a requirement (often indicated by the presence of the word “and”)
Avoid clauses like “if that should be necessary.”
Avoid wishful thinking: 100% reliability, running on all platforms, pleasing all users, handling all unexpected failures.
It is a good practice to separate user requirements from more detailed system requirements in a requirements document
The rationale associated with requirements is very important. It helps in managing changes to requirements
Questions ?