Software Engineering. Lecture 10

Transcription

1 Software Engineering Lecture 10

2 1. What is software? Computer programs and associated documentation. Software products may be: -Generic - developed to be sold to a range of different customers - Bespoke (custom) - developed for a single customer according to their specification

3 What is software engineering? Software engineering is an engineering discipline (regulation), which is concerned with all aspects of software production. Software engineering is concerned with theories, methods and tools for professional software development

4 2. Software Requirements In this section we want to: To introduce the concepts of user and system requirements To describe functional and non-functional requirements To explain two techniques for describing system requirements To explain how software requirements may be organized in a requirements document

5 2.1 Requirements engineering Requirement Engineering: The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed Requirements: are the descriptions of the system services and constraints that are generated during the requirements engineering process

6 2.2 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

7 Requirements Levels of description: - requirements definition: high-level abstract description of requirements - requirements specification: detailed description of what the system should do - Software specification: More detailed description

8 Requirement Abstraction (Davis) 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

9 2.3 Types of requirement User requirements (requirements definition): Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers System requirements (requirements specification): 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

10 Example: User requirement: 1. The software must provide means of representing and accessing external files created by other tools. System requirements 1.1 the user should be provided with facilities to define the type of external files. 1.2 each external file type may have an associated tool which may be applied to the file 1.3 each external file type may be represented as a specific icon on the users display

11 2.4 Functional and non-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.

12 Functional requirements What inputs system should accept? What outputs system should produce? What data the system should store? What computations system should perform?

13 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.

14 Example User requirement Functional requirement: A need for an authorization facilities in the system Non Functional requirement: security

15 2.4.1 Functional requirements Describe functionality or system services Depend on: 1. the type of software 2.expected users 3.type of system where the software is used

16 Functional user requirements may be highlevel statements of what the system should do Functional system requirements should describe the system services in detail (inputs, outputs)

17 Examples of functional requirements for a university Library system 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)

18 Requirements imprecision Problems arise when requirements are not precisely stated Ambiguous requirements may be interpreted in different ways by developers and users results in: delays system delivery, increase cost 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.

19 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 impossible to produce a complete and consistent requirements document

20 Functional Requirements Examples

21 Example 1: Withdrawing money from ATM The system shall provide an option to withdraw money. The system shall query the user for the amount of money. The system shall query the user for the account type. The system shall validate the amount is available in the user s account before releasing funds to the user.

22 Example 1: Withdrawing money from ATM The system shall validate the amount is a multiple of $20. The system shall debit the user s account upon withdrawal of funds. The system shall be able to issue a specific amount of money to the user.

23 Examples of BAD Functional Requirements The system shall validate and accept credit cards and cashier s checks. What is the Problem in this requirement? Problem :two requirements instead of one. Suppose this Scenario: If the credit card processing works, but the cashier s check validation does not is this requirement pass or fail? Has to be fail, but that is misleading.

24 Examples of BAD Functional Requirements The system shall process all mouse clicks very fast to ensure user s do not have to wait. What is the Problem in this requirement? Problem: This is not testable. Quantify how fast is acceptable?

25 Examples of BAD Functional Requirements The user must have Adobe Acrobat installed. What is the Problem in this requirement? Problem: This is not something our system must do. It could be in the constraints/assumption but is not a functional requirement.

26 Non-Functional Requirements Examples

27 Example 1: Withdrawing money from ATM The system must handle 1,000 transactions per second (time/space bounds). user-friendliness. Interfaces with other systems (Interface requirements). system must have less than 1hr downtime per three months(reliability). permissible information flows, or who can do what (security)

28 Example 1: Withdrawing money from ATM system will need to survive fire.(safety) development time limitations, resource availability, limits on development. (Delivery) The customer must be able to access their account 24 hours a day, seven days a week. (reliability)

29 2.4.2 Non-functional requirements Define system properties and constraints Properties: reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Some non functional requirement may constrain the PROCESS used to develop the system.

30 Process requirements : specification that the design must be produced by a particular CASE system( Computer Aided Software Engineering), programming language or development method. Requirement?? Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless (implementation)

31 Examples of process requirements The development process to be used must be explicitly defined and must be conformant with ISO 9000 standards. What type of requirement? (Standard) The system must be developed using the XYZ suite of CASE tools. What type of requirement? (implementation) A disaster recovery plan for the system development must be specified What type of requirement? (safety)

32 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.

33 Non-functional requirements examples Product requirement 4.C.8 It shall be possible for all necessary communication between the system and the user to be expressed in a user friendly interface Requirement is: Organisational requirement The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95.Requirement is: External requirement The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system (privacy) Requirement is: (Privacy) (usability) (standards)

34 Some Types of non-functional requirements with examples

35 Examples of Product requirements The System service X shall have an availability of 99%. Reliability Product Non functional System Y shall process a minimum of 8 transactions per second. Performance Efficiency Product Non Functional The executable code of System Z shall be limited to 512Kbytes. Space Efficiency Product Non Functional it specifies the maximum memory size of the system

36 Examples of Product requirements The system shall be developed for PC and Macintosh platforms. Portability Product Non Functional

37 Example of External requirement The system must encrypt all external communications using the RSA algorithm. Privacy legislative External Non Functional

38 Examples of external requirements In Medical data system : all data is maintained according to data protection legislation before the system is put into operation. Privacy legislative External Non Functional

39 Examples of External requirements The system shall not allow that the dose delivered to the patient to be greater than the maximum value which is determined by the patient s physician. Safety legislative External Non Functional The system shall not operate if the external temperature is below 4 degrees Celsius Safety legislative External Non Functional

40 Consistency between Functional and Nonfunctional Requirements. Example 1: To address security concerns one might have several choices, among them, setting a two level password or to use biometrics. Using a two level password would conflict with usability concerns while the use of biometric devices might conflict with cost concerns

41 Consistency between Functional and Nonfunctional Requirements. Example 2: We could have the following functional requirement: The system must have a file containing all the clients to be used by the Marketing Division. Together with this functional requirement we have the following NFR: This file must be complete enough to allow the Marketing Division to analyze prospective new clients. But an NFR associated with client s attendance states: Patient s admission must take less than 4 minutes. In this case, having a comprehensive file with all the information needed by the marketing division would possibly be conflicting with the goal of admitting a patient in less than 4 minutes.

42 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.

43 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.

44 Metrics for specifying non-functional requirements Performance Speed - Number of processed transactions per second - User/event response time - Screen refresh time Size - Kilobytes - Number of RAM chips

45 Robustness - Time to re-start after system failure -Percentage of events causing failure -Probability of data corruption on failure Integrity - Maximum permitted data loss after system failure

46 Some Objective Metrics for Nonfunctional Requirements Reliability - Mean time to failure - Probability of unavailability - Rate of failure occurrence - Availability

47 Ease of Use - Training time taken to learn 75% of user facilities - Average number of errors made by users in a given time period - Number of help frames Portability - Percentage of target-dependent statements - Number of target systems

48 Example: 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.

49 Requirements Evolution and Management Reasons for requirements change: 1- User gains better understanding of the requirements from the requirements elicitation, analysis and validation process. 2- New ways of working result from the introduction of the SW system itself. 3- Changes to the environment of the organization. 4- Changes to systems or processes within an organization.

50 Consequences of requirements change: Depends when in the life cycle the requirements change Best case review requirements specification Worst case changes to requirements, design, implementation, tests and documentation Modular design can minimize changes

51 Two Classes of Requirements Enduring Requirements Volatile Requirements

52 Enduring Requirements: Derived from an organization s core activity Relate directly to the problem domain Relatively stable

53 Volatile Requirements Derived from the environment of the system Likely to change during development or afterwards

54 Classes of Volatile Requirement Emergent from improved understanding of the problem. Consequential as a result of using the delivered system. Mutable from changes to the environment of the organization. Compatibility from changes to processes within the organization

55 Requirement documents and guidelines: 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 requirement. Avoid the use of computer jargon.

56 The software requirements document: The requirements document : is the official statement of what is required of the system developers. Sometimes called the software requirement specification (SRS).

57 The software requirements document: Should include both a definition of user requirements and a specification of the system requirements. There are three cases: User and system requirements may be integrated into a single description User requirements are defined in an introduction to the system requirements specification If there are large number of requirements, the detailed system requirements may be presented as a separate document

58 The software requirements document: 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

59 IEEE requirements standard Defines a generic structure for a requirements document that must be instantiated for each specific system. Introduction. General description. Specific requirements. Appendices. Index.

60 Requirements document structure based on IEEE standard Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index