Software Engineering Chapter 4 Requirements E n g

Software Engineering Chapter 4 Requirements E n g i n e e r i n g Dr. Doaa Sami Modified from Sommerville’s originals

Objectives 2 Understand the concepts of user and system requirements. Show differences between functional and nonfunctional requirements. Understand how requirements may be organized in a software requirements document. Understand the principal requirements engineering activities of elicitation, analysis and validation. Understand why requirements management is necessary.

Requirements Engineering 3 Requirements: The descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements Engineering (RE): The process of finding out, analyzing, documenting and checking these services and constraints. Developed during the first phase in the software development life cycle.

What is a Requirement? 4 It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. “If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system. ”

Requirements Types 5 User Requirements Statements in a natural language plus diagrams of the services that system provides and its operational constraints. Written for customers. System Requirements A structured document setting out more detailed to define exactly what should be implemented, descriptions of the system’s functions, services and operational constraints. Written for those who are involved in system implementation. A user requirement may expanded into several system requirements.

User & System Requirements Example 6

Readers of different types of requirements specification Chapter 4 Requirements 7

User Requirements Vs. System Requiremen 7 User Requirements Written for customers. Statements in natural language. Describe the services that system provides and its operational constraints. May include diagrams or tables. Should describe functional and nonfunctional requirements. Should be understandable by system users who don’t have detailed technical knowledge. We provide a definition for a user requirement. System Requirements Statements that set 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. Intended to be a basis for designing the system. Can be illustrated using system models. We provide a specification for a system requirement.

Functional & Non-Functional Requirements 8 Functional Requirements Statements of services the system should provide, specify how the system should react to particular inputs or situation. • They say what the system is supposed to do, not do. Non-Functional Requirements Defines system properties and constraints such as timing constraints, constraints on the development process, etc. • Applied to the system as a whole, rather than individual system features or services. Domain Requirements Derived from the domain of operation. They may be new functional requirements that constrain existing functional requirements.

Functional Requirements 9 Describe functionality or system services. Depend on: The type of software being developed. Expected users. The general approach taken by the organization. Functional user requirements may be high- level statements of what the system should do. Functional system requirements should describe the system services in detail, that includes input and outputs.

The LIBSYS Case Study 10 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.

Functional Requirements for LIBSYS 11 1. The user shall be able to search databases for a specific materials. 2. The system shall provide appropriate viewers for the user to read documents in the document store. 3. 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.

Ambiguous Requirements 12 Problems arise when requirements are not precisely stated (Ambiguous). Ambiguous requirements may be interpreted in different ways by developers and users. Consider the term ‘appropriate viewers ’ in requirement(2) of LIBSYS: User intention – special purpose viewer for each different document type. Developer interpretation –provide text viewer that shows the contents of the documents.

Requirements Completeness and Consistency 13 In principle, requirements should be both complete and consistent. Completeness: All services required by the user should be defined. Consistency: Requirements should not have contradictory descriptions or definitions. In practice, for large and complex systems, it is impossible to produce a complete and consistent requirements document.

Non-Functional Requirements 14 Define system properties rather than specific services. Example of non-functional requirements: Ø System properties: reliability, response time, maintainability, storage requirements. Ø Constraints: I/O device capability, data representations, etc. Ø Process requirements: Mandating particular CASE system, Programming language.

Non-Functional Requirements Classifications 15 Product Requirement Specify that the delivered product must behave in a particular way e. g. Performance: how fast systems is, and Reliability: acceptable failure rate. Organizational Requirement (process requirement) Requirements which are a consequence of organisational policies and procedures e. g. process requirements that define how the system will be used. External Requirements which arise from factors which are external to the system and its development process e. g. Interoperability: how system work with other system on other organization, Legislative requirements law requirements.

Examples of nonfunctional requirements in the MHC-PMS Product requirement The MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830– 17. 30). Downtime within normal working hours shall not exceed five seconds in any one day. Organizational requirement Users of the MHC-PMS system shall authenticate themselves using their health authority identity card. External requirement The system shall implement patient privacy provisions as set out in HStan-03 -2006 -priv. Chapter 4 Requirements 17

Non-Functional Requirements Classifications 16

Non-Functional Requirements Implementation 17 Non-functional requirements may affect the overall architecture of a system rather than the individual components. For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. It may also generate requirements that restrict existing requirements.

Goals and Requirements 18 Common problem with non-functional requirement is that user express them as a general goal. Goals: General intention of the user such as ease of use. Verifiable Non-Functional Requirement: Statements using some measures that can be objectively tested. Goals are helpful to developers as they convey the intentions of the system users.

Example 19 Goal: The system shall be easy to use. Better expressed as: Experienced users 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.

Non-Functional Requirements Specifying Metrics 20 Property Measure Speed User/event response time Screen refresh time Size Number of ROM chips Ease of use Training time Reliability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Number of target systems

Domain Requirements 21 The operational domain of the system imposes requirements on the system. For example, a train control system has to take into account the braking characteristics in different weather conditions. Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable.

LIBSYS Domain Requirement 22 Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.

Domain Requirements Problems 23 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.

Software Requirements Specification (SRS) 24 Representing requirements using SRS document: The software requirements specifications document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set WHAT the system should do rather than HOW it should do it.

Ways of Writing a SRS 25 1. Natural language The requirements are written using numbered sentences in natural language. Each sentence should express one requirement. 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.

Problems with Natural Language 26 Lack of clarity Precision is difficult without making document difficult to read. Requirements confusion Functional and non-functional requirements tend to be mixed-up. Requirements Mixture Several different requirements may be expressed together.

Example requirements for the insulin pump software system 3. 2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels. ) 3. 6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible. ) Chapter 4 Requirements 29

Ways of Writing a SRS 27 2. Structured natural language The freedom of the requirements writer is limited. Requirements are written in a standard form or template. Each field provides information about an aspect of the requirement. 3. Mathematical specifications These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification.

Ways of Writing a SRS 28 4. Graphical models Supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.

Use cases for the MHC-PMS Chapter 4 Requirements 32

Users of the SRS Document 29 Customers check that requirements meet needs. Managers plan developments process. System engineers understand what system to be developed. System test engineers develop validation tests for the system. System maintenance engineers understand the system and the relationships between its parts.

Structure of a Requirements Document 30 Chapter Description Preface This should define the expected readership of the document and describe its version history, Introduction This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. Glossary This should define the technical terms used in the document. User Requirements definition Here, describe the services provided for the user. The non-functional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that are understandable to customers. Product and process standards that must be followed should be specified. System architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted.

Structure of a Requirements Document Cont. 31 Chapter System Requirements specification Description This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements. Interfaces to other systems may be defined. System Models This might include graphical system models showing the relationships between the system components and the system and its environment. System Evolution This should describe the fundamental assumptions on which the system is based, and any anticipated changes due to hardware evolution, changing user needs, and so on. Appendices These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions and Hardware requirements. Index Several indexes to the document may be included.

Requirements Engineering Processes 32 The processes used for RE vary widely depending on the application domain, the people involved and organisation developing the requirements. However, there are four generic activities which common to all requirements engineering processes: 1. Feasibility study. 2. Requirements elicitation and analysis. 3. Requirements specification. 4. Requirements validation. the

Requirements Engineering Processes 33

1. Feasibility Study 34 Feasibility study decides whether or not the proposed system is worthwhile. A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are used.

A spiral view of the requirements engineering process Chapter 4 Requirements 39

2. Requirements Election and Analysis 35 software engineers work with customers and system end-users to find out about the application domain, the services that the system should provide and the system’s operational constraints. May involve a variety of different kinds of people in an organization: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. Can you identify possible stakeholders for the LIBSYS?

2. Requirements Election and Analysis Cont. 36 Requirements Discovery Sources of information Documentation ex: Existing documents and files (business mission, sample forms, flowcharts. . . etc. System stakeholders by: Interviews. Observation (ethnography). Questioners. Specifications of similar systems (reports).

System Models 37 Requirements Analysis (System Models) The model aids the analyst in understanding the system, thereby makes the requirements analysis easier and more systematic. The model becomes the focal point of review. The model becomes foundation for design. Produced during requirements analysis.

3. Requirements Specifications 38 Requirements specifications o It is the final work product produced by the requirements engineer. o The SRS document o It serves as a foundation for the software design and implementation.

4. Requirements Validation 39 The process of ensuring that the requirements actually define the system that the customer wants. Why is it important? The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors.

4. Requirements Validation Cont. 40 Validity checks Is this what the user wants? Consistency checks Requirements should not conflict Completeness checks Requirements should define all functions and constraints Realism checks Ensure they could be implemented Verifiability Requirements should be written so that they are verifiable, you should be able to write tests for each requirement.

Requirements Validation Techniques 41 Requirements reviews A team of reviewers manually check the requirements. Prototyping An executable model of the system is demonstrated to customers. Test-case generation Requirements should be testable. If tests are difficult or impossible to design, this means that the requirements will be difficult to implement.

Requirements Management 42 Requirements Management is the process of controlling changes to system requirements. New requirements emerge as a system is being developed and after it has gone into use. You need to keep track of individual requirements and maintain links between dependent requirements, so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.

Requirements change management Chapter 4 Requirements 48

Summery 43 Requirements for a software system set out what the system should do and define constraints on its operation and implementation. Functional requirements are statements of the services that the system must provide or are descriptions of how some computations must be carried out. Non-functional requirements often constrain the system being developed and the development process being used.

Summery 44 You can use a range of techniques for requirements elicitation including interviews, scenarios and usecases. Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism and verifiability. Business, organizational and technical changes inevitably lead to changes to the requirements for a software system. Requirements management is the process of managing and controlling these changes.