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
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
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.
Features of Non-FunctionalRequirements1. Non-Functional requirements mostly define the overall attributes of the “resulting” system.
IEEE Standard 830 – 1993• List of 13 non-functional requirements: 1. Performance 2. Interface Examples? 3. Operational 4. Resource 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: 1. Performance: 100 transactions per minute 2. Interface: capable of importing data with EDI format 3. Operational: must not require more than 1 megabyte of main memory 4. Resource: will use wireless encryption algorithm that is “better” than WEP 5. Verification: all data updates must be traceable 6. Acceptance: must pass a user defined system test bucket 7. Documentation: user manual is needed for novice users only 8. Security: user request to access any data must be authorized first 9. Portability: the system must operate with “any” relational db systems 10. Quality: the system must install with zero defect 11. Reliability: the system must be accessible 99.9 % of the time 12. Maintainability: the system must be modifiable (e.g. designed with exits) 13. 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
Difficulties in SpecifyingNon-functional Requirements
Difficulties in SpecifyingNon-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 similar they can not be well understood or validated until much later • e.g. reliability or quality – Certain non-functional requirements may be conflicting • e.g. performance .vs. security .vs. reliability – Certain non-functional requirements may be difficult to express and validate; may require more refinements.
“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 measures Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use T raining time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness T ime to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability 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
Relationships between userneeds, concerns and NFRs
Relationships between userneeds, concerns and NFRsUser’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. 3. Ease of interfacing Verifiability 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 4. Expandability capacity or performance ?
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
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