1. 1 To introduce the concepts of user and system requirements To introduce the concepts of user and system requirements To describe functional and non- functional requirements To describe functional and non- functional requirements To explain how software requirements may be organised in a requirements document To explain how software requirements may be organised in a requirements document Objectives

2. 2 Requirements Engineering The process of establishing the services that a customer requires from a system and the constraints under which it can operate and should be is developed. Sommervil 04 The process of establishing the services that a customer requires from a system and the constraints under which it can operate and should be is developed. Sommervil 04 The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

3. 3 What is a requirement? Requirements are the set of things that a customer requires with a number of constraints that must be satisfied on the final system. Requirements are the set of things that a customer requires with a number of constraints that must be satisfied on the final system. It can be represented in high-level abstract statement of a service a detailed mathematical functional specification. It can be represented in high-level abstract statement of a service a detailed mathematical functional specification. Requirements may serve as: Requirements may serve as: The basis for a bid for a contract - therefore must be open to interpretation;The basis for a bid for a contract - therefore must be open to interpretation; The basis for the contract itself - therefore must be defined in detail;The basis for the contract itself - therefore must be defined in detail;

4. 4 Examples of Requirements “Fire Alarm must go off when a movement is detected before 06:00 and after 19:00” “Fire Alarm must go off when a movement is detected before 06:00 and after 19:00” “The system must dial 999 to inform the Police” “The system must dial 999 to inform the Police” “Customers should be able to view their remaining balance” “Customers should be able to view their remaining balance” “The system should identify employee by face” “The system should identify employee by face”

5. 5 Requirements Engineering Can be described in: Elicitation Elicitation Analysis and negotiation Analysis and negotiation Specs generation Specs generation System modeling System modeling Validation Validation Management Management

6. 6 Why Reqs are non-tech? User cannot understand technical details User cannot understand technical details Maybe they could after system Launched! Maybe they could after system Launched! Reduce restrictions on code developers Reduce restrictions on code developers Satisfy requirements using whatever possible techniques and tools. Satisfy requirements using whatever possible techniques and tools. Customer may specify details that might confuse more than clarify! Customer may specify details that might confuse more than clarify! Fast system, large size, easy to use … etc Fast system, large size, easy to use … etc Requirement might change over time Requirement might change over time

7. 7 Characteristics of good Spec. Implementation Free Implementation Free Omit technical details.Omit technical details. Complete Complete Should include descriptions of all facilities required.Should include descriptions of all facilities required. Consistent Consistent There should be no conflicts or contradictions in the descriptions of the system facilities.There should be no conflicts or contradictions in the descriptions of the system facilities. Unambiguous Unambiguous Common vocabularies are used.Common vocabularies are used. Ambiguous requirements may be interpreted in different ways by developers and usersAmbiguous requirements may be interpreted in different ways by developers and users Concise and Minimal Concise and Minimal No duplication or un-necessary contents.No duplication or un-necessary contents. Clear and Understandable Clear and Understandable Testable Testable Example: “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”.Example: “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”.

8. 8 Exercise Are The following statements right or wrong Specs? “ “Write a Java program to provide a personal telephone directory. It should implement functions to look up a number and to enter a new telephone number. The program should provide a friendly user interface.” “ Data should be stored in Magnetic Disk and the system must retrieve data in 1ms”

9. 9 Types of requirement User requirements User requirements Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. System requirements System requirements A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.

10. 10 Functional and non-functional requirements Functional requirements 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.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 Non-functional requirements constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Domain requirements Domain requirements Requirements that come from the application domain of the system and that reflect characteristics of that domain.Requirements that come from the application domain of the system and that reflect characteristics of that domain.

11. 11 Functional requirements Describe functionality or system services. Describe functionality or system services. Depend on the type of software, expected users and the type of system or environment where the software is used. Depend on the type of software, expected users and the type of system or environment 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. 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.

12. 12 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. 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 authorizing a particular CASE system, programming language or development method. Process requirements may also be specified authorizing 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 requirements may be more critical than functional requirements. If these are not met, the system is useless.

13. 13 Example of Non-Functional Reqs The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system. The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

14. 14 Elicit Requirements The activity of eliciting requirements involves the engineer and users talking together, with the former trying to understand the latter by asking questions and writing notes.

15. 15 Elicitation Techniques Background reading Background reading Documents inspection Documents inspection Interviews Interviews Questionnaires Questionnaires Brainstorming Brainstorming Ethnography Ethnography Prototyping Prototyping Use-cases and scenarios Use-cases and scenarios

16. 16 What to Elicit? Description of problem domain. Description of problem domain. medical, chemistry, math … etc. medical, chemistry, math … etc. List of Problems. List of Problems. Any client-imposed constraints upon behavior or structure of the system. Any client-imposed constraints upon behavior or structure of the system. The main motivation behind the development. The main motivation behind the development.

17. 17 Sources of Information Client Client Documentation of Pre-exiting system Documentation of Pre-exiting system Users of pre-existing system Users of pre-existing system Possible users of the new system Possible users of the new system Competitor’s product Competitor’s product Domain Expert Domain Expert Relevant standards Relevant standards

18. 18 Guidelines for writing requirements Invent a standard format and use it for all 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 language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. Use text highlighting to identify key parts of the requirement. Use text highlighting to identify key parts of the requirement. Avoid the use of computer terminology. Avoid the use of computer terminology.

19. 19 Problems with natural language Lack of clarity Lack of clarity Precision is difficult without making the document difficult to read.Precision is difficult without making the document difficult to read. Requirements confusion Requirements confusion Functional and non-functional requirements tend to be mixed-up.Functional and non-functional requirements tend to be mixed-up. Requirements amalgamation Requirements amalgamation Several different requirements may be expressed together.Several different requirements may be expressed together.

20. 20 Sequence diagrams These show the sequence of events that take place during some user interaction with a system. These show the sequence of events that take place during some user interaction with a system. You read them from top to bottom to see the order of the actions that take place. You read them from top to bottom to see the order of the actions that take place. Cash withdrawal from an ATM Cash withdrawal from an ATM Validate card;Validate card; Handle request;Handle request; Complete transaction.Complete transaction.

21. 21 Sequence diagram of ATM withdrawal

22. 22 System Behavior Modeling Data Flow Diagram (DFD) Data Flow Diagram (DFD) Graphical representation of the flow of data throughout a system. (see e.g. P175) Graphical representation of the flow of data throughout a system. (see e.g. P175)

23. 23 System Behavior Modeling State Transition Diagram (STD) State Transition Diagram (STD) Describes the possible states of an object as events occur Describes the possible states of an object as events occur

24. 24 Key points Requirements set out what the system should do and define constraints on its operation and implementation. Requirements set out what the system should do and define constraints on its operation and implementation. Functional requirements set out services the system should provide. Functional requirements set out services the system should provide. Non-functional requirements constrain the system being developed or the development process. Non-functional requirements constrain the system being developed or the development process. User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams. User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.