– Software Requirements – Descriptions and specifications of a systemObjectives:q To introduce the concepts of user and system requirementsq To describe functional / non-functional requirementsq To explain two techniques for describing system requirementsq To explain how software requirements may be organised in a requirements document
Requirements engineeringRequirements engineering is the process of establishingq the services that the customer requires from a systemq the constraints under which it operates and is developed Requirements The descriptions of the system services and constraints that are generated during the requirements engineering process
What is a requirement?• It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification• This is inevitable as requirements may serve a dual function – May be the basis for a bid for a contract - therefore must be open to interpretation – May be the basis for the contract itself - therefore must be defined in detail – Both these statements may be called requirements
What are requirements? Application Domain Machine Domain C - computers D - domain properties R - requirements P - programs• Domain Properties: – things in the application domain that are true whether or not we ever build the proposed system• Requirements: – things in the application domain that we wish to be made true by delivering the proposed system •Many of which will involve phenomena the machine has no access to• A Specification: – is a description of the behaviours that the program must have in order to meet the requirements
What are Requirements?• Two basic principles of requirements engineering: – Separate the problem from the solution – Problems and solutions intertwine with one another• Describing problems: – Application Domains vs. Machine Domains – Verification vs. Validation• Systems Engineering – Systems vs. software• Patterns and Types of Problem – Requirements patterns – Problem Frames
Separate the problem from the solution• A separate problem Problem description is useful: Situation – Most obvious problem might not the right one to solve Validation – Problem statement can be Problem Correspondence Verification discussed with Statement Correctness stakeholders – Problem statement can be used to evaluate design choices – Problem statement is a Implementation source of good test cases Statement• Still need to check: – Solution correctly solves the stated problem – Problem statement System corresponds to the needs of the stakeholders
Fitness for purpose?• Two correctness (verification) criteria: – The Program running on a particular Computer satisfies the Specification – The Specification, in the context of the given domain properties, satisfies the requirements• Two completeness (validation) criteria: – We discovered all the important requirements – We discovered all the relevant domain properties
Example• Requirement R – “The database shall only be accessible by authorized personnel”• Domain Properties D: – Authorized personnel have passwords – Passwords are never shared with non-authorized personnel• Specification S: – Access to the database shall only be granted after the user types an authorized password.• S + D entail R
But we can also move theboundaries…• E.g. Elevator control system: people waiting Elevator call buttons Scheduling algorithm people in the elevator Floor request buttons people wanting to go to button lights a particular floor Current floor indicators Control program Motor on/off Elevator motors Door open/close Safety rulesWe can shift things around: E.g. Add some sensors to detect when people are waiting This changes the nature of the problem to be solved
What do Requirements Engineersdo?• Some notion that there is a “problem” that needs solving – dissatisfaction with the current state of affairs – a new business opportunity – a potential saving of cost, time, resource usage, etc.• Requirements Engineer is an agent of change
The requirements engineer must:• Identify the “problem”/”opportunity”• Which problem needs to be solved? (identify problem Boundaries)• Where is the problem? (understand the Context/Problem Domain)• Whose problem is it? (identify Stakeholders)• Why does it need solving? (identify the stakeholders’ Goals)• How might a software system help? (collect some Scenarios)• When does it need solving? (identify Development Constraints)• What might prevent us solving it? (identify Feasibility and Risk)• And become an expert in the problem domain
Types of requirement• User requirements• System requirements• Domain requirements• Functional requirements• Non-functional requirements
Types of requirement• User requirements – Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers• System requirements – A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor• Software specification – A detailed software description which can serve as a basis for a design or implementation. Written for developers
Functional and non-functionalrequirements• Domain requirements – Requirements that come from the application domain of the system and that reflect characteristics of that domain• Functional requirements – Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.• Non-functional requirements – constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
User requirements• Should describe functional and non- functional requirements so that they are understandable by system users who don’t have detailed technical knowledge• User requirements are defined using natural language, tables and diagrams
System requirements– More detailed specifications of user requirements• Serve as a basis for designing the system• May be used as part of the system contract• System requirements may be expressed using system models
Domain requirements• Derived from the application domain and describe system characteristics and features that reflect the domain• May be new functional requirements, constraints on existing requirements or define specific computations• If domain requirements are not satisfied, the system may be unworkable
Domain requirements problems• Understandability – Requirements are expressed in the language of the application domain – This is often not understood by software engineers developing the system• Implicitness – Domain specialists understand the area so well that they do not think of making the domain requirements explicit
Functional Requirements Describe functionality or system services• Depend on the type of software, expected users and the type of system where the software is used• Functional user requirements may be high- level statements of what the system should do BUT functional system requirements should describe the system services in detail
The LIBSYS system• A library system that provides a single interface to a number of databases of articles in different libraries.• Users can search for, download and print these articles for personal study.
Examples of functionalrequirements• The user shall be able to search either all of the initial set of databases or select a subset from it.• The system shall provide appropriate viewers for the user to read documents in the document store.• Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.
Requirements imprecision• Problems arise when requirements are not precisely stated• Ambiguous requirements may be interpreted in different ways by developers and users• Consider the term ‘appropriate viewers’ – User intention - special purpose viewer for each different document type – Developer interpretation - Provide a text viewer that shows the contents of the document
Requirements completeness and consistency• In principle requirements should be both complete and consistent Complete – They should include descriptions of all facilities required Consistent – There should be no conflicts or contradictions in the descriptions of the system facilities• In practice, it is very difficult or impossible to produce a complete and consistent requirements document
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.• 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.
Non-functional requirementsexamples• Product requirement – 4.C.8 It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard Ada character set• Organisational requirement – 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95• External requirement – 7.6.5 The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system
Goals and requirements• Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.• Goal – A general intention of the user such as ease of use• Verifiable non-functional requirement – A statement using some measure that can be objectively tested• Goals are helpful to developers as they convey the intentions of the system users
Examples• A system goal – The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised.• A verifiable non-functional requirement – Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.
Features of Non-Functional Requirements1. Non-Functional requirements mostly define the overall attributes of the “resulting” system – Most of the time these turn out to be “constraints” on how the (functional) requirements are to be met. • (e.g.) Response time must be .xyz second per screen – Sometimes the functional requirements may have to be “sacrificed or increased” in order to meet the non-functional requirements • (e.g.) in order to satisfy security requirements, we can not let everyone access the system --- sacrificing some flexibility • (e.g.) in order to satisfy the reliability requirements, we may add a duplicative functionality to provide another path to achieve the desired result
Features of Non-Functional Requirements1. Some non-functional requirements may not address the attributes of the resulting system (product), but something else – (e.g.) the system must be developed with a very risk averse process such as Spiral or the system must be developed with Visual Basic language
IEEE Standard 830 – 1993• List of 13 non-functional requirements: 1. Performance 2. Interface 3. Operational 4. Resource Examples? 5. Verification 6. Acceptance 7. Documentation 8. Security 9. Portability 10. Quality 11. Reliability 12. Maintainability 13. Safety Some of these also overlap - - - - - -
IEEE Standard 830 – 1993• List of 13 non-functional requirements Examples: – Performance: 100 transactions per minute – Interface: capable of importing data with EDI format – Operational: must not require more than 1 megabyte of main memory – Resource: will use wireless encryption algorithm that is “better” than WEP – Verification: all data updates must be traceable – Acceptance: must pass a user defined system test bucket – Documentation: user manual is needed for novice users only – Security: user request to access any data must be authorized first – Portability: the system must operate with “any” relational db systems – Quality: the system must install with zero defect – Reliability: the system must be accessible 99.9 % of the time – Maintainability: the system must be modifiable (e.g. designed with exits) – Safety: the system must not perform “chemical material discard” functions without “explicit” user authorization. There may be others that are important such as meeting legal standards that Is not mentioned in this list
Sommerville’s Classification of Non-Functional Requirements Process Product External Oriented Related DirectedDelivery/Updates Usability Legal rulesImplementation Reliability EconomicsProcess standards Safety Interoperability Efficiency Performance Capacity
These are constraints placed on various activities related to the development and delivery of the software product. For example: Process 1.The development organization must be CMM Oriented level 3 or above. 2. The system must use some specific tool. 3. There must be a disaster recovery plan for the systemDelivery/Updates 4. There must be an agreed to product delivery planImplementationProcess standards Why do we have these requirements? Large organizations such as fortune 500 companies or government agencies are experienced with quality, maintenance, and delivery problems from past. These requirements are meant to minimize those problems.
These are constraints which specify the desired “attributes” that the system must possess. Note: - Some can be specified quantitatively and precisely; others are difficult to quantify and are informally specified. Product - Sometimes these requirements may be mutually conflicting Related (e.g. reliability versus efficiency) Examples: Usability 1.The system must process 100 transactions per minute 2. The system must not require 1 meg of main memory 3. The mean time between failure must be 3 months Reliability 4. The average user learning time must be less than 1 day 5. The system must be available 99.99% of time Safety Efficiency Why do we have these requirements?Performance Many organizations have critical needs; Aviation or Health Systems may have safety, reliability, and Capacity performance needs beyond the normal processing environment
These are constraints which may be placed on both the product and/or process. For example:Externally Directed 1.The system must abide to HIPAA (Health Insurance Portability and Accountability Act) privacy rules 2. The system must meet European Sales Tax laws 3. The system must use Automotive EDI for B2B Legal rules e-commerce EconomicsInteroperability Why do we have these requirements? Many countries have specific financial laws, privacy protection laws, etc. that the system must abide to. Some industries have their own business rules to conduct commerce.
Difficulties in SpecifyingNon-functional Requirements
Difficulties in Specifying Non-functional Requirements• The difficulties in gathering Non-Functional Requirements may be attributed to many reasons - - - - - mostly because people tend to focus on the functions and services that they need: – Certain non-functional requirements are sometimes hard to quantify and therefore hard to express without some “trial and error prototyping”. • e.g. : usability – Certain non-functional requirements are hard to differentiate between functional and non-functional • e.g. security – Certain non-functional requirements are difficult to specify because they can not be well understood or validated until much later • e.g. reliability or quality – Certain non-functional requirements may be conflicting similar • e.g. performance .vs. security .vs. reliability – Certain non-functional requirements may be difficult to express and validate; may require more refinements • e.g. when to stop prototyping usability if the users do not clearly signal satisfaction
“Critical” Systems• Critical systems are systems whose failure causes significant economic, human or organizational damage: – Business Critical System • e-commerce systems such as stock trading, reservations, etc. – Mission Critical System • Aircraft control, manufacturing process control, etc. – Safety (life) Critical system • Medical Device control, hazardous materials management, etc.
Requirements for System Criticality• Most of the requirements for these “business,” “mission,” and “safety” criticality deals with non-functional requirements of the a) “complete” system, not just software and b) may be expressed in general ways that need to be decomposed further: – Performance – Reliability – Security – Usability – Safety Again, these may be “conflicting” - - - - so what do you do? Must prioritize the requirements, especially when there are conflicts
Performance Related Requirements• These requirements mostly addresses the constraints of speed and sometimes capacity: – System Response time to end-user such as 1 second response to user requests – System throughput such as # of transactions per minute (time interval) – System timing such as collection of data and responding to it within sub-second for real-time system. – System capacity such as number of simultaneous users that may access an application (instantaneous time) These should be specified quantitatively.
Reliability Related Requirements• These requirements addresses constraints on run-time behavior of the system: – System Availability such as the system is up certain percentage of the time. – System Failure rate such as average mean time between system failures to deliver the user service. These should also be specified quantitatively.
Security Related Requirements• These requirements addresses the issues related to unauthorized access: to the system, to specific function, to data: – System Access protection such as firewall requirement – Application Functional Access & Usage protection such as authorization and authentication requirement – Data Access and Usage protection such as authorization and encryption requirement Security is also an important factor for other requirement such as safety. A little hard to specify these quantitatively.
Usability Related Requirements• These requirements addresses the user interface looks and user inter- actions with the system – Entry and beginners-level knowledge assumption to use the system – Learning time and experience needed such as hours or number of lessons to learn the system – Handling and usage such as time to complete certain tasks or number of errors made before completing certain tasks – Likeness and delight experienced from using the system such as availability of context sensitive help text or “re-do” capability Some of these requirements can be and should be specified Quantitatively; delight and likeness are a bit hard to define.
Safety Critical System Requirements• These requirements addresses everything with the safety of the system and of the usage of the system.• These requirements deal mostly with the “shall not” requirements such as: – The system shall not allow - - - - – The system will not operate without - - - Note that safety may be dependent on many of the other requirements: - insecure system may be open to malicious danger - unreliable system may fail unpredictably and hurt someone - non-responsive system may miss critical data and damage something - difficult to use system may create a critical human error
Requirements measuresProperty MeasureSpeed Processed transactions/second User/Event response time Screen refresh timeSize K Bytes Number of RAM chipsEase of use T raining time Number of help framesReliability Mean time to failure Probability of unavailability Rate of failure occurrence AvailabilityRobustness T ime to restart after failure Percentage of events causing failure Probability of data corruption on failurePortability Percentage of target dependent statements Number of target systems
Requirements and design• In principle, requirements should state what the system should do and the design should describe how it does this• In practice, requirements and design are inseparable – A system architecture may be designed to structure the requirements – The system may inter-operate with other systems that generate design requirements – The use of a specific design may be a domain requirement
Objectives• To introduce non-functional requirements• To explain the schemes used to classify non- functional requirements• To illustrate various derivation techniques for non-functional requirements• To demonstrate the importance of non- functional requirements in critical systems
Non-functional requirements (NFR)• Non-functional requirements define the overall qualities or attributes of the resulting system• Non-functional requirements place restrictions on the product being developed, the development process, and specify external constraints that the product must meet.• Examples of NFR include safety, security, usability, reliability and performance requirements.
Functional and Non-functional requirements• There is no a clear distinction between functional and non-functional requirements.• Whether or not a requirement is expressed as a functional or a non-functional requirement may depend: – on the level of detail to be included in the requirements document – the degree of trust which exists between a system customer and a system developer.
Example• The system shall ensure that data is protected from unauthorised access. – Conventionally, this would be considered as a non- functional requirement because it does not specify specific system functionality which must be provided. However, it could have been specified in slightly more detail as follows: • The system shall include a user authorisation procedure where users must identify themselves using a login name and password. Only users who are authorised in this way may access the system
Types of Non-functional requirements• The ‘IEEE-Std 830 - 1993’ lists 13 non- functional requirements to be included in a Software Requirements Document. – Performance requirements – Interface requirements – Operational requirements – Resource requirements – Verification requirements – Acceptance requirements
Classification of NFRs• NFRs may be classified n terms of qualities that a software must exhibit (Boehm)• A more general classification distinguishes between product, process and external requirements
Classification of NFRs (contd.) Nt a oc l ni - o f n un ri e em q n u t r s e P rs oc es Ptq e r cu n or i t d r s u e em El x ta er nri eemq n u t r s e ri e em q n u t r s e U ri e si e m a q n b u t i lt yr s eDey lr i ve Le g alri eemq n u t r s e Rte m el ri e li q n ii u t abyr s e ca oi nt s s tn ri leoma pn et n m ti Sr i e a em f q n eu t t yr s e Ei c c o nomri e em q n u t r s e ca oi nt s s tn r sa t r ad n ds Ec u n fer i e f nq t i yr s c em i e Ir rl nei tp t ea oibyri eemq n u t r s e ri e em q n u t r s e P ae m e nq e r cu n f ei t o rr s r m e C ri e ay r n p em a q t c u s i t e
Product requirements• Specify the desired characteristics that a system or subsystem must possess.• Most NFRs are concerned with specifying constraints on the behaviour of the executing system.
Specifying product requirements• Some product requirements can be formulated precisely, and thus easily quantified – Performance – Capacity• Others are more difficult to quantify and, consequently, are often stated informally – Usability
Examples of product requirements• The System service X shall have an availability of 999/1000 or 99%. This is a reliability requirement which means that out of every 1000 requests for this service, 999 must be satisfied.• System Y shall process a minimum of 8 transactions per second. This is a performance requirement.• The executable code of System Z shall be limited to 512Kbytes. This is a space
Source code requirements• There are product requirements which relate to the source code of the system• Examples – The system shall be developed for PC and Macintosh platforms. This is a portability requirement which affects the way in which the system may be designed – The system must encrypt all external communications using the RSA algorithm. This is a security requirement which specifies that a specific algorithm must be used in the product
Conflicts in product requirements• Product requirements are often conflict. For example: – A requirement for a certain level of performance may be contradicted by reliability and security requirements which use processor capacity to carry out dynamic system checking – A requirement on the space utilisation of the system may be contradicted by another requirement which specifies that a standard compiler which does not generate compact code must be used• The process of arriving at a trade-off in these
Process requirements• Process requirements are constraints placed upon the development process of the system• Process requirements include: – Requirements on development standards and methods which must be followed – CASE tools which should be used – The management reports which must be provided
Examples of process requirements• The development process to be used must be explicitly defined and must be conformant with ISO 9000 standards• The system must be developed using the XYZ suite of CASE tools• Management reports setting out the effort expended on each identified system component must be produced every two weeks• A disaster recovery plan for the system development must be specified
External requirements• May be placed on both the product and the process• Derived from the environment in which the system is developed• External requirements are based on: – application domain information – organisational considerations – the need for the system to work with other systems – health and safety or data protection regulations – or even basic natural laws such as the laws of
Examples of external requirements• Medical data system The organisation’s data protection officer must certify that all data is maintained according to data protection legislation before the system is put into operation.• Train protection system The time required to bring the train to a complete halt is computed using the following function: The deceleration of the train shall be taken as: γtrain = γcontrol + γgradient where:
External requirement example (contd.)γgradient = 9.81 ms-2 * compensated gradient / alpha and where the values of 9.81 ms-2/ alpha are known for the different types of train.γcontrol is initialised at 0.8 ms-2 - this value being parameterised in order to remain adjustable. The illustrates an example of the train’s deceleration by using the parabolas derived from the above formula where there is a change in gradient before the (predicted) stopping point of the train.
External requirement example (contd.) S p eed of rain at change of gradient S p eed of train on ap p lication of b rakes V γ = γ control+ γ gradient1 γ = γ control+ γ gradient2 Distance Front of train C hange of gradient
External requirement example (contd.)• The first of the the requirements described comes from the need for the system to conform to data protection legislation• The second comes from the application domain and is a specification of the physical braking characteristics of a train.• External requirements rarely have the form “the system shall...” or ‘the system shall not...”. Rather, they are descriptions of the system’s environment which must be taken into account.
Deriving NFRs• NFRs are difficult to express• A number of important issues contribute to the problem of expressing non-functional requirements: – Certain constraints are related to the design solution that is unknown at the requirements stage – Certain constraints, are highly subjective and can only be determined through complex empirical evaluations – Non-functional requirements tend to be related to one or more functional requirements – Non-functional requirements tend to conflict and
Stakeholder concerns• Stakeholders normally have a number of ‘concerns’• Concerns are typically non-functional• Examples include: – Critical business objectives – Essential system characteristics (e.g. security) – Safety, performance, functionality and maintainability• Vaguely defined user concerns may be related to NFRs
Relationships between user needs, concerns and NFRs User’s need User’s concern Non-functional requirementFunction 1. Ease of use 1. Usability 2. Unauthorised access 2. Security 3. Likelihood of failure 3. ReliabilityPerformance 1. Resource utilisation 1. Efficiency 2. Performance verification 2. Verifiability 3. Ease of interfacing 3. InteroperabilityChange 1. Ease of repair 1. Maintainability 2. Ease of change 2. Flexibility 3. Ease of transport ? 3. Portability 4. Ease of expanding or upgrading capacity 4. Expandability or performance ?
Concerns• A way of expressing critical ‘holistic’ requirements• Concerns may be broken down into sub- concerns and finally into specific questions• Questions act as a check list to ensure that specific requirements do not conflict with global priorities
Concern decomposition S a f et y Ci ob m py a tt il i Pl e rs on a Se o f tw a r P h y si c al C o ln l i si o Dt ee r n a il m H ae rr d wa an ct ci d e En T x e cu t io i g If m n i n tc e r ae Ee xp c e e d ss s Tm rd a a c g k e a E e n n v t im r o n f ans o ci r kt t on r d c i o Wt a h ri b a mu to n i a o n ot f Wm i ri ee l e nt lq t c ar a u f e fSmey ubs s l t e ta m bt eo tkgqb rd i uy am i c ar r a s e eed t e af ho ee e r ch p n rfm otd n dse det aoe e ax c vc t i s ts ? i i h mt e y Hs s o t e wsh e ga xs r i o? s fe t t i w nspee d pd re o v i? d Du te o qe d e i n s r n a e e r m e Smt tt e y uc h d s s ue te t m e r e i x nu e stUt dn a isd ci e on rwt h o n d t v a ia l ta a as i e t nl ht ab At en d u ve a in n e or t xn m ec i occ euae esns d esc xp e s a tu Ha h t Sf rh Tc o e ir ? gh nt e edeenr ta? i l m Wc ee r y hse eae a s d ia te s nl does m i xp n? t Cu b a ft e nn t c h i i s o n p den r e ht oo x vn i i dt s e g eien xno ? e n e c vn u im tor t
Goal-based derivation• Relates non-functional requirements to the goals of the enterprise• Goal-based NFR derivation is a 3 step approach: – Identify the enterprise goal – Decompose of the goal into sub-goals – Identify non-functional requirements.
Example of goal-based derivation Go al IS - g o al motivates The system should perform in Visualise air traffic scenarios real-time OM motivates IS - NFR IS - NFR Display radar data The display must accommodate in real-time all data from the scenario motivates motivates IS - NFR Aircraft position should be displayed in less than 3/16 sec of the radar sweep period IS - NFR IS - NFR IS - NFR IS - NFR Display 100 tracks Display 100 Display 200 vectors Display 500 table meteorological plots symbols
Testable NFRs• Stakeholders may have vague goals which cannot be expressed precisely• Vague and imprecise ‘requirements’ are problematic• NFRs should satisfy two attributes – Must be objective – Must be testable (Use measurable metrics)• It is not always possible to express NFRs objectively
Examples of measurable metrics for NFRs Property MetricP erfo rm an ce 1 . P ro cessed tran sactio n s p er seco n d 2 . R esp o n se tim e to u ser in p u tR eliab ility 1 . R ate o f o ccu rren ce o f failu re 2 . M ean tim e to failu reA v ailab ility P ro b ab ility o f failu re o n d em an dS ize K b y tesU sab ility 1 . T im e tak en to learn 8 0 % o f th e facilities 2 . N u m b er o f erro rs m ad e b y u sers in a g iv en tim e p erio dR o b u stn ess T im e to restart after sy stem failu reP o rtab ility N u m b er o f targ et sy stem s
Requirements for critical systems• Systems whose ‘failure’ causes significant economic, physical or human damage to organisations or people.• There are three principal types of critical system: – Business critical systems – Mission critical systems – Safety critical systems
NFRs for critical systems• The principal non-functional constraints which are relevant to critical systems: – Reliability – Performance – Security – Usability – Safety
Reliability• Constraints on the run-time behaviour of the system• Can be considered under two separate headings: • Availability - is the system available for service when requested by end-users. • Failure rate - how often does the system fail to deliver the service expected by end-users.
Performance• Constrain the speed of operation of a system• Types of performance requirements: • Response requirements • Throughput requirements • Timing requirements
Security• Security requirements are included in a system to ensure: – Unauthorised access to the system and its data is not allowed – Ensure the integrity of the system from accidental or malicious damage• Examples of security requirements are: – The access permissions for system data may only be changed by the system’s data administrator – All system data must be backed up every 24 hours and the backup copies stored in a secure location which is not in the same building as the system
Usability• Concerned with specifying the user interface and end-user interactions with the system• Well structured user manuals, informative error messages, help facilities and consistent interfaces enhance usability
Usability metrics• Measurable attributes of usability requirements include: – Entry requirements Measured in terms of years of experience with class of applications or simply age – Learning requirements Denotes the time needed to learn the facilities of the system. This could be measured in terms of speed of learning, say hours of training required before independent use is possible – Handling requirements Denotes the error rate of the end-users of the system. This could be measured in terms of the errors made when
COQUAMO approach to measuring usability• Provides an automated support facility for setting and measuring usability• Provides a set of ‘templates’ which have to be filled in
COQUAMO usability templateCilf oats n s ii c a G l-li en eq a td t na p nd e i p p r t a yion lu c e a eLue iv re e l r d e q H i g hAdist useloqs c a i a i t e sy ys no nm l a o i se s ei p yrl s ai e , rn rl rt e d n, a u i bt yb f n i l i e rdp ect l o ac t n ee su ny nd da e b r i s l t i atDenfiio n i1 t ei h r l t em ah un os s w crue e i s e st w e a s t cs n y haE1xnp .lo1 s io aef e l ssa llcte vi ofafrc e o c e m i s u hv mi rt rc s e i e p w a e ic ot e o e t g s ce p oe f e h v n s y st emMuema ns set u n rt e e i d ay smt a c rfs e f ee g t us od o ya os s oo u r nt s u / r d r v auu i n a e eyml r rs v sM co edtem ia nt se d u o sn u k rt i e n n wi e g n rt a aae n rr r i ue f s m dt 0 b i os e ee rq t 2 uWoers tc a s 8Pelelavne nd l 4Beestc as 2Cvuer e r l e nt l 1 0Jauistt o i n f i c i ot cy t y m si r s X pe ile d Z r nf q b v pl u e e mc e Y a eC cion ln eu c s oe o e f r q f u a e s t
Safety• No consensus in the system’s engineering community about what is meant by the term ‘safety requirement’ – Sometimes considered to be all requirements (functional and non-functional) on safety-related systems – Sometimes the sub-set of these requirements which are directly related to ensuring safe operation and sometimes requirements on protection systems which are designed to protect against accident• Usage of the term often depends on the culture
Safety requirement definition• Informal definition: Safety requirements are the ‘shall not’ requirements which exclude unsafe situations from the possible solution space of the system
Examples of safety requirements• The system shall not permit operation unless the operator guard is in place• The system shall not allow the sedative dose delivered to the patient to be greater than the maximum value which is determined by the patient’s physician• The system shall not operate if the external temperature is below 4 degrees Celsius
Requirements engineering for safety-related systems• The requirements engineering process for safety-related systems should incorporate a specific safety-analysis activity• The widely accepted model of the system critical systems life cycle (BCS and IEE 1989) identifies two stages in the safety analysis process: – Safety requirements discovery – Safety validation
Hazard analysis• As part of the process of safety analysis, there are various activities such as hazard identification and analysis• Various methods such as fault-tree analysis and Petri net analysis have been developed for safety validation
Integrating safety analysis with RE• We illustrate in the following sections a simple technique for integrating safety analysis with a requirements engineering method• The technique is intended to support the process of requirements discovery (safety requirements) and validation
Integrating safety analysis with RE (contd.)• The starting point for specifying the system is a set of abstract organisational needs and constraints• It is important that the approach used incorporates a systematic approach to dealing safety issues. These include: – Identifying hazards, risks and risk criteria – Identifying the necessary risk reduction to meet the risk criteria – Defining the overall safety requirements
Integrating safety analysis with RE (contd.)• The requirements process, shown in , has been extended to incorporate an explicit safety analysis activity• The safety analysis process is based on requirements information drawn from the requirements elicitation and documentation process• A set of abstract safety requirements serves as a reference model for identifying initial safety considerations or concerns
Integrating safety analysis with RE (contd.)• The safety analysis process includes: – The identification of safety considerations – Hazard identification – Hazard analysis – Risk analysis and derivation of safety requirements• Proposed safety requirements are analysed together with other system requirements to ensure that safety is not compromised
Key points• Non-functional requirements define the overall qualities or attributes of the resulting system• Non-functional requirements may be classified into three main types; product, process and external requirements• Product requirements specify the desired characteristics that the system or subsystem must posses• Non-functional requirements tend to conflict and interact with other system requirements• The principal non-functional constraints which are relevant to critical systems are reliability, performance, security, usability and safety
Guidelines for writing requirements• Invent a standard format and use it for all requirements• Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements• Use text highlighting to identify key parts of the requirementAvoid the use of computer jargon !!!
Problems with natural language• Lack of clarity – Precision is difficult without making the document difficult to read• Requirements confusion – Functional and non-functional requirements tend to be mixed-up• Requirements combination – Several different requirements may be expressed together
Alternatives to NL specificationNotation DescriptionStructured This approach depends on defining standard forms ornatural templates to express the requirements specification.languageDesign This approach uses a language like a programmingdescription language but with more abstract features to specify thelanguages requirements by defining an operational model of the system.Graphical A graphical language, supplemented by text annotations isnotations used to define the functional requirements for the system. An early example of such a graphical language was SADT (Ross, 1977; Schoman and Ross, 1977). More recently, use-case descriptions (Jacobsen, Christerson et al., 1993) have been used. I discuss these in the following chapter.Mathematical These are notations based on mathematical conceptsspecifications such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality. However, most customers don’t understand formal specifications and are reluctant to accept it as a system contract. I discuss formal specification in Chapter 9.
The requirements document• The requirements document is the official statement of what is required of the system developers• Should include both a definition and a specification of requirements• It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it
S e if th r q i e e t a d p c y e e u mns n r r a t e t c e k a th y e d h mo h c th t eS s m u t mr y te c so e s me t ern e s T e e t h i e d. h y s e i yc a g stot e p cf h n e h r q ie e t e ur mns Ueth r q ir mn s e e u e e ts Mn g r a a es d c mn t p nab f r o u e t o la id o th s se a dt p nt e e y t m n o la h s s m e eo mn p o e s y te d v l p e t r c s Ueth r q ir mn t s e e u e e ts oSs mni ery te e gn e s u d r t n wa s se ist n e sa d h t y t m o b dv l pd e e eo e S s me t y te t s Ueth r q ir mn t s e e u e e ts o e gn e s ni er d v l pv li aio t ssf r e eo a d t n e t o th s se e yt m Users of a Ss m y te Ueth r q ir mn t h lp s e e u e e ts o e requirements mi t n n e ane a c u d r t n t es s m n n esa d h y te a d th r laio s i sb t e ni e e t n hp ewe ts document e gn e s ni er pr ats
Requirements document requirements• Specify external system behaviour• Specify implementation constraints• Easy to change• Serve as reference tool for maintenance• Record forethought about the life cycle of the system i.e. predict changes• Characterise responses to unexpected events
IEEE requirements standard• Introduction• General description• Specific requirements• Appendices• Index• This is a generic structure that must be instantiated for specific systems
Requirements document structure• Introduction• Glossary• User requirements definition• System architecture• System requirements specification• System models• System evolution• Appendices• Index