Non-Functional requirements
Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless
Non-Functional classifications
Product requirements Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Organisational requirements Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. External requirements Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.
Portability requirements
Interoperability requirements
Ethical requirements
Usability requirements
Delivery requirements
Standards requirements
Legislative requirements
Performance requirements
Privacy requirements
Safety requirements
Requirements measures
Prope rty Speed Size Ease of use Reliability Measure Processed transactions/second User/Event response time Screen refresh t ime K Byt es Number of RAM chips Training t ime Number of help frames Mean time t o failure Probabilit y of unavailability Rate of failure occurrence Availabilit y Time to restart after failure Percent age of events causing failure Probabilit y of dat a corruption on failure Percent age of t arget dependent statements Number of t arget syst ems
Stake Holders
Stake holders different people who would be interested in the software. Management carries a lot of weight, but are they the actual users? Acceptance of the software depends upon whom? Stakeholders have very general and vague requirements. Some times they trivialize things. Different stake holders have different requirements sometimes even conflicting. Analysis takes place in an organizational context internal politics may influence requirements.
Stake Holders
Management Marketing
Provides Business Requirements and Project Parameters Specifies High Level Requirements
Software Requirements allocates system requirements to software describe user requirements and quality attributes specifies hardware interfaces the software must respect
Systems Engineering
Users
Hardware Engineering
User Requirements
Quality Attributes
System Requirements
Functional Requirements
Constraints
Business Requirements
Example of conflicting business requirements page 97 Priority setting = Msword
An Example
In this example an embedded system is to be developed for a booth. This system will be sold to the retail stores and will be used by the store customers.
Conflicting Objectives
The developer might want to establish a high-tech and exciting new direction for the customer, while the retailer wants a simple, turnkey system, and the customer wants convenience and features.
Vision Statement
Example chemical tracking system Assumptions and dependencies Scope
Vision Statement
An Example
The Chemical Tracking System will allow scientists to request containers of chemicals to be supplied by the chemical stockroom or by vendors. The location of every chemical container within the company, the quantity of material remaining in it, and the complete history of each containers location and usage will be known by the system at all times. The company will save 25% on chemical cost by
Vision Statement
An Example - continued
fully exploiting chemicals already available within the company, by disposing of fewer partially used or expired containers, and by using a standard chemical purchasing process. The Chemical Tracking System will also generate all reports required to comply with federal and state government regulations that require the reporting of chemical usage, storage and disposal.
Context Diagram
Sources of Requirements
Customer-Developer Relationship
Excellent software products are the result of a well-executed design based on excellent requirements. High quality requirements result from effective communication and coordination between developers and customers.
Building a relationship
Learn about the business
It is not a computer science problem the problem lies in a different domain than computer science and you must understand it before you can solve it.
Personal experience SFA tool for Telecom
Use Cases
Actor
An entity that has an interest in interacting with the system a human or some other device or system.